Currently in UE4, replication support is only available for primitive types (int, float, bool, etc.), structs, and Actors (and subclasses of Actor). While this is a great start, I would like to open a discussion on why the root of the replication hierarchy is at Actor and not at Object.
In many games, it is convenient to create “data objects”: objects that encapsulate data and simple functions, but do not have a presence in the world space. For example, many games have a “inventory”: a set of items a player is currently carrying. While these items could be Actors, in most cases this is overkill. The additional overhead of a transform, inherited properties from Actor, and inflexibility in class hierarchy is unnecessary for these “data objects”.
Instead, it would be useful if Object (the root class exposed to developers) supported replication out-of-the-box. Actor would still benefit from automatic replication (Actor is an Object subclass, AFAIK) and developers would have the option for a tradeoff of subclassing from Actor or Object for their replication needs.
This is not a rebuttal to why UObject should be the root replication mechanism. I have attempted to add custom replication capabilities to some of my classes in C++, but ended up abandoning those things because replication outside of the Actor class hierarchy is vastly unsupported, undocumented, and unstable. If UObject had replication mechanisms to begin with, simple data class would be easy to build, and Actor would be able to extend replication as needed for its own purposes.
I agree, but actually you can do this in other ways.
First one is the UObject replication… actually i did a very complex multi sized inventory system ( WIP Full Multiplayer support Grid Inventory System in UE4 - YouTube ), which have a hidden uobject layer to save unique item datas… like if magazine - ammo number, if weapon - loaded bullets and so on…
But actually now im thinking some parsing system…
that means i want to use simple replicated struct data, but structs will have String.
In that string i can save unique datas in gived form (like loadedbullets=10;isjammed=true) and i can parse this to useable form
basically idea is use string as “data object”
of course uobject replication is the best if will be supported ever from engine naturally
UObjects are Lightweight by Design. They don´t support a lot of things out of the Box but thats on Purpose. You have however the possibility to make them Network Capable but thats up to you if AActor is to Heavy for your needs.
If we would make UObject Network Capable by default you would have no base Class left that is not Network Capable and in return you need to remove the Network Capability out of the Object by Hand. There are over 2200 Classes derived from UObject and almost all of them don´t need replication (keeping it light). So it makes sense to turn replication on by default for a Class above → AActor in that case, aswell let this class manage replication of UObjects he holds. (Or Components they should work fine to if you need something more decoupled you can drop onto any Actor like a Inventory Component)
So no it won´t happen most likely.
But hey you can Request better Docs, Examples even to be covered in a Training Session. Thats something that would help you along right?
Alright, fair enough. A dedicated UObject+Replication subclass, built and endorsed (and therefor documented and maintained) by Epic would be, well, epic.
I feel like the ability to replicate a subclass of uobject would be incredibly useful though. Structs in BP can get really messy to work with. Uobjects can do everything a struct can and a lot more. Supposedly they already support replication, you just have to flag it in c++. I would think that this would be a very beneficial feature for people trying to handle more complex data driven gameplay. I know that when i cranked out an inventory with both structs and uobjects, the uobject one was far cleaner, more flexible, supported object specific scripting (i didnt have to play another pointer in the struct to direct the inventory to ANOTHER object)…
I’m sure it’s some more work and thought on Epic’s side, but I would think that this would be very handy for a lot of people that just don’t use it because it’s not an option.
Now we run Into a Architectual Questions =) Its Possible technicly but than you run into Deep Layering of Classes or Branching of the Class Hiearchy with duplicated Code (replication Process) you have to maintain in two places (or more) now.
Same thing would apply for saying something like you like a UObject that is placeable in the Level. Or having a UObject that can hold Components etc. etc.
All nice things to have but makes Codemangement more Complex if you Understand what I mean. But thats something where I say I put my trust into the Senior Developers. If its a good Idea or any other Options that are better to mentain and Scale.
My Personal guess is that chance are low that we get a dedicated Lightweight Network Object since the Functionality to make it replicate it is there.
Well whatever it comes down to I dont mind the existense of such Network Object.
