UE6 has stated that it will deprecate Blueprints and Actors. While deprecating Blueprints is fine, deprecating Actors means that components cannot GetOwner and then use the Owner’s interface to access other components. If we fully shift to ECS, this is extremely bad news for the current code. I hope UE6 can retain the option of interface-oriented programming for the long term, rather than removing Actors in the future.
Look at the SceneGraph in UEFN for a preview of how the world will be composed in UE6:
You are merely introducing me to the ECS programming paradigm in Fortnite, but you haven’t answered my question.
When searching for components along the entity tree, and when writing components, one has no idea what the entity tree they are attached to looks like. Even if they do know, there’s no guarantee that it won’t be modified in the future, or that the component won’t be used on an incompatible entity tree.
Obviously, it is not the same thing to initialize all components in an Actor, make the Actor programmable, implement interfaces, make components completely unaware of what the Actor is, and define the scene component tree of the Actor through code.
Interfaces aren’t going away. They are a basic programming paradigm that are supported by verse.
The docs I posted outline the relationships between entities and components including how interfaces change based on composition.
I don’t see how interfaces could disappear: At the very least, they won’t be able to eliminate the concept of class inheritance in C++. And if classes still exist then interfaces also still exist… Because interfaces are just multiple class inheritance in C++.
I hope UE6 can retain the option of interface-oriented programming for the long term, rather than removing Actors in the future
I’m not sure how these two concepts correlate. Actors are not necessary for interfaces to work.
In fact, for some ungodly reason, you could, right now, fetch a generic interaction component from your candidate actor, and check if the component implements some kind of interface or not. It’s not just actors.
Likewise, even without a fully fledged ECS, you can right now work exclusively through components, without interfaces. Instead of checking if an actor implements an interface, you can try and fetch a component of a certain class on the actor. As a form of functionality verification.
you guys are still talking about object orientated though, which my understanding is UE6 wont be.
i cant think of a reason for them to exist in data orientated design, since the existence of data defines its contract, but maybe someone can enlighten me there.
if you want that design you’re stuck on UE5 i think
It absolutely will be. Or at least parts of it will be. UObjects aren’t going away. It’s unclear if Entities will be UObjects or not. The components are probably UObjects (you’ll probably need to derive at least once to make a new one). They both are right now, but that could change.
Even in DOD, you can use interfaces to provide a consistent API that is abstracted from the actual data. That’s literally what they are for. Using them as accessors to components is silly in my opinion (as Altrue points out, you should just get them through the Actor interface). Something like IGameplayTagAssetInterface would still be relevant if I want to be able to ask lots of different components for it’s collection of Gameplay Tags. You wouldn’t want them to derive from a common type with actual data in it, just an interface that lets them apply whatever they’re already storing in their own data.
I haven’t followed it all yet since its years away but it makes no sense for Entities to be UObjects, since ECS is all about tightly packed data and not pointer jumps.
but then its all verse anyway? does that use UObjects?
either way im not saying they’ll remove it, just that they probably wont support it going forward
I don’t recall Epic saying anything about ECS. The Game Framework replacement is Scene Graph. Scene graphs are not necessarily mutually exclusive with ECS implementations, but neither does it require one.
The Engine already has an ECS-style tightly packed data through Mass.
In the current UE6 main, entities and components are UObjects. I doubt this will change. Those interested, look in Engine/Plugins/EntityFramework for the Entity, component, and scenegraph code. I don’t know if everything will follow the ECS pattern. There is stuff in there using the hydration/dehydration pattern Mass Entity uses (although some of that is temporary scaffolding for using AActors until they are replaced).
Navigation around the scenegraph will be different than the current AActor/ActorComponent traversal for sure, and looks more robust than the current methods.
Interfaces are a design pattern (aka Protocol). While super useful, there is a lot of overhype in this community on their use as a panacea of OOP, that often does nothing but add technical debt. Also it prevents cache pre-fetch, normally not a big deal, but can be a performance consideration.
Actually, we hope to have an ECS framework that can be used, but it should also be up to us to decide when to use it. For example, a login logic:
The client has a GameInstanceSubsystem to manage Widget pointers, as well as PlayerID and Token Then, when launching a login, first find the LocalPlayerController, then access the interface function to obtain a pointer such as PlayerLoginComp, and then call the internal RPC function to submit the user name and password to the RPC implementation of PlayerLoginComp in the PlayerController of the DedicatedServer. Then this implementation searches for GameMode, and after finding GameMode, it finds PlayerLoginManager (which is a self implemented component on GameMode) through the interface. Then PlayerLoginManager caches the request and finds the Socket component on GameMode through the interface, and sends a message to the Java server. The Java server queries through JDBC and returns to the Socket component on GameMode. The Socket component calls the delegate, and the PlagerLogin Manager component receives the delegate. It finds the requested PlayerController in the request cache, retrieves the PlayerLoginComp, and then RPC calls to return a message indicating whether the client has successfully logged in. The client calls the GameInstanceSubsystem function to display the message Widget. There are multiple types working together here, some components are on PlayerController, some components are on GameMode, and some are GameInstanceSubsystems. Both PlayerController and GameMode are actors. If a component only knows itself, it is difficult for it to complete complex functions, or it may become a universal class. For example, a login component on a PlayerController needs to have the ability to establish a TCPSocket connection and send messages.
This example illustrates that data-driven approaches are not suitable for all tasks. Of course, the ECS framework has great advantages in game oriented businesses such as updating character coordinates. So what I hope for is that both modes can coexist and allow us to decide what to use based on our actual business.
I have even thought of such a plan, that is, if one day Actor really doesn’t exist, I will implement the component base classes A and B .
Class A components are placed on the root entity, and the constructor of it or its subclasses is written in code to add sub entities to the root entity. Then add several B-class components to the sub entity.
Then the components of subclasses of Class B have a pointer of Class A called Owner. The constructor of Class A sets the Owner of these Class B components to itself. Then A holds pointer array to all B-class components.
Then, all subclasses of Class B can use GetOwner to obtain Component A, and the A object implements the interface provided by each module to obtain Class B components.
Implementing the code decision entity tree and code decision components in this way.
Currently the ‘ECS’ data driven aspect in the UE6 code is set up to be ‘opt-in’ for entities. An entity can have fragments and processors to be processed by Mass, and ‘hydrate’ from that data when needed. It’s not required to use the Mass system.