How to choose between UObject and AActor

[thek3nger]

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.

Thanks

[Nanoxin]

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

Actors are instances of classes that derive from the AActor class; the base class of all gameplay objects that can be placed into the world. Objects are instances of classes that inherit from the UObject class; the base class of all objects in Unreal Engine, including Actors. So, in reality, all instances in Unreal Engine are Objects; however, the term Actors is commonly used to refer to instances of classes that derive from AActor in their hierarchy, while the term Objects is used to refer to instances of classes that do not inherit from the AActor class. The majority of the classes you create will inherit from AActor at some point in their hierarchy.

In general, Actors can be thought of as whole items or entities, while Objects are more specialized parts. Actors often make use of Components, which are specialized Objects, to define certain aspects of their functionality or hold values for a collection of properties. Take a car as an example. The car as a whole is an Actor, whereas the parts of the car, like the wheels and doors, would all be Components of that Actor.

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!

[Nemori]

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

[thek3nger]

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

I lack experience too.
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.

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.

Yes. There are so many ways to do the same things that my "developer anxiety" get crazy. 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.

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

[dzeligman]

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

[thek3nger]

Oh. Good to know! Thanks.

[iniside]

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.

[ambershee]

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!