Download

Actors, Objects, or Structs?

Development Discussion C++ Gameplay Programming
#1

Hi!

What is fastest to create many of, AActors, UObjects, or UStructs? Is the difference appreciable?

I am spawning in new actors at the rate of, say, 5 per second, and each actor upon upon spawning also needs to create a data system that has an array of 50+ data structures that has an array of 100+ data structures. I am concerned that this might get to be a lot, so before I finish developing, I’m curious if anyone has any input as to the computationally fastest way to do it. I’m assuming that spawning an AActor takes far more processing time than spawning a UObject? I could make each data structure into a struct defined within the top-level actor’s class, or I could break each data structure into its own object with an array of subobjects.

to facilitate understanding:
GameActor contains ArrayOfLayers[Layer * 50]. Layer contains ArrayOfDoodles[Doodles * 50]

If I should be doing something else entirely, I’m open to that too :slight_smile:

Thanks!
Zach

#2

UStructs are the fastest and are below the UObject subsystem level, which means they are also incredibly much more stable cause you can have hard references and not have to use pointers

buuuut

UStructs dont have built in timer support or ability to access the world context unless it is passed into them.

At no time should you prefer an Actor for the sort of thing you are doing, the Actor Draw Count bottleneck is something you will hit pretty quick with that many actors as you describe!

so best thing you can do is try not to need timers in the structs themselves, and encapsulate your data in UStructs

UStructs will always be the best for what you are asking as they are also the simplest, simply the encapsulation of some variable data really.

But it depends on what you need each piece of your data to do!

I do think you should make it work with UStructs :slight_smile:

This is the kind of situation which I always go with UStructs and it works out very well, every time, and is very stable.

With UStructs, you can do everything by reference (no pointers anywhere) and it just works.

Rama

PS: Just make sure to .Empty() your TArrays of UStructs() when you are done with them :slight_smile:

#3

Great, thanks Rama!

#4

There are few questions you must answer yourself first:

  1. Do I need replication (networking support on my object). If Yes you want to use actor. You can of course use UObject or even plain C++ class, but you will need to write custom networking replication support for these, and it is by no means easy task to tackle.

  2. Does my objects need to be placed in level ? If yes you probably want to use Actor. Creating placeable UObject is easier than networked one, but but I don’t think it’s really worth effort.

  3. Do I need garbage collection ? If yes, you can use either UObject or AActor. You can also implement custom class with Garbage Collection enabled. But UObject overhead is not something you should be concerned with.

  4. Do I need editor/blueprint support. If yes, use AActor or UObject.

  5. If your object, is just simple data store, for properties, then you probably just want to use USTRUCT.

Memory overhead from AActor and UObject is not something you should be really concerned. Single texture will take more memory, than doznes of Actors.
Spawning of Actors is heavy, but as I was pointed on on IRC, is not something to be concerned with. Games are not real time application, and there many factors responsible for game responsiveness, and spawning new objects at run time is one of possible hundreds of factors, and not even most important one.

Get it working first, and then start worrying about how it works, otherwise you will never get something working ;).

Another fact. If you are planning to creating (by using new) 50k objects in single batch on single thread, you can be sure that thread will be locked for some time, regardless of how simple your objects are. In that case I would really reconsider your design first.

  1. Deffer creating object to what you really need at time.
  2. Try spawning object in separate thread, and then pass references to them to your main working thread. Just a thought, I’m not really expert on multi threaded programming, so I dunno if that is possible (;.

Simplifying data structure you are using to store/manipulate your data, is often most obvious solution, but it doesn’t means is the best one.
It will just simplify problem, but won’t fix it.