I’m discovering the UE4 API, and i’m actively searching for accurate and consise explanation of all the underlying philosophy and concept of the engine in simple word.
Basically you have some clean drawings that explain you all the global logic of things without going too much in the code detail, but after reading those you really get the impression of being less idiot without having burn too much neurone at the same time …
Does stuff like that exist for UE4 ?
One of the core concept i would like to understand is Inheritance VS Composition. It looks that you have 2 main philosophy for class organisation in a game.
Inheritance → is-a relationship between objects
Composition → has-a relationship between objects
It looks that UE4 is now base on an entity/components logic , but at the same time you also have a huge inheritance logic , so something that clarify what is what would be cool. From what i understand UE4 use a hybrid approach with inheritance for certain aspect and composition for others.
The core of UE4 looks to be the UObject class from this class you build Actors and Components Child class.
The UActor class is an empty box for components
The Components class are giving a has a properties to Actors
Does i get it right ? Or my conclusion are not accurate ?
Thanks for reading this far too long post , and thanks for your time !
You know, those are code reviews… so why don’t you send email to that guy to make review for UE4, ofcorse in borders of licence Problem might be UE4 is a lot more complicated then idTech’s as idTech is not made to offer high end tools for 3rd party
Your conclusion is right. Epic leaves it up to the developer for how they want to architect their games. At my studio we only inherit for the sake of making code based “prefabs” that are fully type defined. Components are harder to design, but make the code so much cleaner.
You’ve got the gist of it right. One thing though is that the class is AActor, not UActor. Components are meant to be a has-a relationship. The component model is a newer feature of the engine and inheritance was used historically. This is why the engine is a hybrid of the two. One thing to note is that while the component based design can be cleaner, it often suffers from performance problems that can be alleviated by using a less clean approach of inheritance.
but since UE4 it has evolve to a hybrid approach by adding a composition base logic.
You are free and you have the possibility to build your game in 2 ways:
Focus on inheritance = The code is more messy and less flexible but a lot more faster.
Focus on composition = The code is elegant and very flexible but you have worst performance.
So i guess that if you work on a an indie game / small project your best bet is to go the composition way , but if you work on a AAA FPS and TPS that need kickasss graphics you will go the inheritance way … so i guess internally EPIC is using inheritance over Composition ?
I would maybe have other question for you guys ! Does this principle of Inheritance = rigide but faster VS Composition = Flexible but slower is a general truth , or does it is UE4 specific due to the fact that components are an additional layer build on top of a hierarchical structure ?
I would also have a lot of few question around the API to understand the global logic of UE4.
From what i have understand 90% of the UE4 engine magic is contain in 3 Class : Core / CoreUObject / Engine.
Core is the EPIC fundamental low level library where key function extensively use by the engine but not directly related to the gameplay are stored (math …) , the equivalent of idLib in idTech4.
CoreUObject is really the legoland of UE4 the most fundamental classwhere all entities / actor / camera / components / trigger / scripts are defined if you understand this one you understand a lot …
Engine is the last important one, but i have a problem with this one because basically many of it’s class looks to be defined in CoreUObject, so i really don’t get what is the purposeof engine vs CoreUObject ?
But basically those 3 class define the game logic of UE4 and could be consider to be the equivalent of the idClass in gamex86.dll for idTech4.
Now i would like to be sure to get a proper understanding of the rest. As a guy who want to build custom logic or shaders, we just need to focus on the Runtime section and sometime the plugin section . All the class contain in Editor and Developer section doesn’t interest us.
So let’s go back to what interest us and try to understand how Runtime section work:
Everything start with an UI, and EPIC has build SLATE his own framework “a la Qt” to build all their app : games and editor , but we could also build other software with this UI framework. The class Slate / SlateCore / SlateRHIRenderer / UMG are all the one we need to build GUI with UE4.
We also need to get input to send them to the game engine Those input are managed by InputCore / InputDevice class.
Then we need a renderer and basically UE4 use at his core a hardware renderer that intercept the command from the game to describe the graphic outpout. This renderer is call RHI and use EmptyRHI / NullDrv / RHI class to work. Then the RHI scene is translatedinUE4Core renderer which is DX11 based thus the final outpout is defined in RenderCore / Renderer / ShaderCore class , that implement the directX11 renderer. If the platform doesn’t support DX11 then this DX11 scene description is then send to an OpenGL translator contained in OpenGLDrv class.
The shaders that are defined in Umaterial use shading models defined in the Engine\Shaders folder. those HLSL shaders can be converted to GLSL if needeed with hlslcc.
Like we said game logic is defined in (CoreUobject/Engine). and this is evaluated in the game main loop contain in the Launch Class.
Game can also rely on AIModule classe for AI computation and PhysXformats for Physics computation
Does this looks accurate to you guys ? because i’m trying to make a nice drawing of what is what in UE4 to get the global pictures of it.
Thanks a lot for the brave enough readers that have made the effort to read this very very wordy post !
Thanks again for taking the time to help in my humble beginings in front of the beast !
I would be careful with conlusions about inheritance and composition runtime speed.
“The code is more messy and less flexible but a lot more faster.” It is NOT A LOT more faster. I doubt it will be faster at all.
Where do you lose performance with components? When calling functions on them, or when they are called automatically by the subsystems and some functions have to be called every tick. In an inheritance situation you still would have to call these functions and provide that data to subsystems, if you want the funcionality. Lets say at least by calling Super::MyParent() or if you inherit from something like Collideable you/a subsystem would have to trigger all the getShape etc. functions still.
So basically the whole performance overhead is the “Do you have component? Ok then give me Component reference.” mechanic in subsystems that are updating and using the components. - If that little performence lost there (if any) becomes a problem, the game has 1000 other problems before this, that have nothing to do with component design.
So I would take care to not create myths when writing about it.
Also more complexity and prefering inheritance over composition raises development and debugging time because “My car has a radio” is a better abstraction and though easier to handle then “My car is also a radio”. And cleaner, generic solutions are easier to opitimize than complex specialized, what would then again lead to more speed. In my oppinion at least.
On the other head, yes a ground up vehicle driving engine expecially coded for vehicle driving and nothing else, or an ultra small, hard coded, highly spezialized Gameboy Super Mario game, might perform better compared to a generic engine for any gametype.
Many Thanks for your detail answer ! I was more basing my assumption on Joe Answer to be honest, as i am totally ignorant about UE4 programming.
I am also far more fan of the composition logic, coming from a C background . All those class that inherit from other and sometime from multiple class, where you have to go hunting in your class hierarchy to understand what is what , is one of the reason i still prefer C. Of course i guess for such huge project as UE4 C++ is a necessity and a wise choice. But i agree with you that this inheritance logic is not what i prefer.
