How to choose between UObject and AActor

Hi. I have some question on how to organize my classes. In particular, I don’t really know when to prefer AActor over UObject.

From what I understood, AActor is designed to be used for object that have to be spawned in the level while UObject is just a generic object. However, I’ve seen people use AActor also for non-physical objects (such as “spells”). So I’m a bit confused on how to chose between the two.

To be more concrete, this is my actual case. I have a Map object that store some metadata plus a grid collection of Tiles. Now, Tiles are actors because I have to spawn them in the level, interact with them and so on. But I’m not sure if the Map should be an actor too or an uobject that is used to spawn the tiles.

Anyway, I’d really really enjoy more information, opinions or experiences on how do you choose between uobject and aactor in your projects. :slight_smile:

Thanks

You might want to take a look here: https://docs.unrealengine.com/latest/INT/Programming/UnrealArchitecture/index.html

Spells e.g. take place in the world and can be seen as “individuals” (they could theoretically be placed in the editor, even though for spells that doesn’t really make sense). Your case is somewhat special … I guess? Does the Map itself need to be specialized? (You could store that in the GameInstance / GameState Class f.e. (you’d need to know where to put it exactly though, not sure about those two))
If it doesn’t need to be placed in the World I would tend not to use an AActor class, but an UObject? I’m not too experienced though with the details of the Unreal Architecture :S

Good luck! :slight_smile:

Hello,

the way I understand it (correct me if I’m wrong) is that Actors are Objects that live in a level, i.e. level kind of owns them. While (U)Object is just a generic base class for objects in the engine. If there is no explicit owner, they will get garbage collected. Also Actors can have components which give them more functionality (position in space, physics, whatever) and interact nicely with blueprints and other Actors. So in your case I guess you could either have your Map as an Actor who manages tiles, or as an Object that is a property of your GameMode class. Another option is to use normal C++ class and manage it’s lifetime manually.

You might also try putting your Map code into your GameMode class, many ways to accomplish things :slight_smile:

I lack experience too. :slight_smile:
Just to provide more information, the Map flow should be: I read a file, I create a Map based on that file, I draw the map into the level.

Yes. There are so many ways to do the same things that my “developer anxiety” get crazy. :smiley: I also thought to make Map an Actor and then make a component to handle the tiles (something like theInstancedMeshComponent).

However, thank you for your feedback. In the next days I’ll try some solutions. :slight_smile:

If some one else want to share other opinions, I’ll be glad to hear them! :slight_smile:

To keep things simple for meta data type objects I’d inherit from AInfo, which is an actor with some defautl functions overridden. Its what epic does for GameState, GameMode etc

Oh. Good to know! :slight_smile: Thanks.

UObject:
Base class without any properties. Which make it very lightweight and can be used as data store if you need your class blueprintable for one reason or another. It can’t be replicated on it’s own nor can be placed in level by default.
UObjects are automatially garbage collected, if they are not hard referenced in object which is not garbage collected.

AActor:
Have lots of properties by default. Not all of them can be useful for you, but it’s not a reason to fuss about it.
Actors are replicated by default and can be placed in levels (everything placed in level is actor of some sort).
Actors are not garbage collected and my be explicitly destroyed.

When to use which one ? If you need your class to be blueprintable, but you don’t need components, replication or placing in level UObject will be good.

For anything else you probabaly want actor.

I usually ask myself a fairly simple question - does my object need a location in the game world? If so, use Actor and if not, use Object. That’s often all it boils down to!

2 Likes

If I wish to use UObject for multiplayer, I may have to use server-RPC for adding or deleting the Uobject into memory right?
Is that a good practice?
I do not wish to use AActor because, if I go to another level, the AActor objects will have to be instantiated right?
Please correct me if I am wrong.

UObjects dont replicate by default and both need to be instantiated so you’ll lose them on level change.

Actor components can be a middle ground between actors and objects too

Can I still use server-RPC methods inside a UObject derived class? Is that a good idea for multiplayer?

its a great idea that lyra uses but doesnt come standard meaning you’ve have to create a c++ class and set up the replication yourself