Subsystems vs ActorComponents

Development Programming & Scripting
1

I was extending Subsystems(SS) to blueprint for my game but the further i got in i just couldn’t see the point.

both kinda auto instantiate, SS you have to create in c++ and possibly add to the Asset Manager, then restart editor, Actor Components(AC) you just add to say the Game State.

Both have controlled lifetimes. Both are good for modular game design/ plugins/modules

SS you have to extend for BP use and for Tick, AC does both already

SS can be forced to replicate but its very clunky. AC replicate out of the box.

SS has a nice getter function, AC can just make one in the function library.

I suppose the real deal breaker is Replication but I just cant see the point of Subsystems. Anything i’m missing?

2

A subsystem is primarily a singleton object, unlike components. This has its pros and cons in certain cases.

It is also worth remembering that the lifespan of the components is the same as that of the world subsystem.
But you can also create a game instance subsystem, or an editor subsystem which have their own lifetime.

Depending on the task, both of these tools are worth using, it’s just that often components are used much more often, since a set of typical tasks are solved more elegantly with the help of components.

3

yeah i understand them, i just couldn’t find much use for them.
I agree they’re good for Editor Extensions but in game components just seem better.

4

Working as a team, many of us wanted to have our own GameInstance, and Subsystems helped a lot with that.

1 Like
5

speaking of i hope you’re working on the next Alien vs Predator, love those games! haha

1 Like
6

Unfortunately. But if I were offered this, my answer would be predictable. :kissing_smiling_eyes:

1 Like
7

Subsystems give more freedom in development approaches. I consider Subsystems as “Managers”. For instance, speaking of game systems, to make a Time of Day manager, or Stats Tracking manager (tracks FPS in game and sends it to server) I would never go with ActorComponents, and stick to subsystems instead. ActorComponents are meant to be used as parts of Actors and they have a lot of Actor-related variables, as you mentioned, replication, physics etc. Thus you are not forced to set an Actor as a parent, if I don’t need those features, bare bones Subsystem without all those capabilities might fit better.

Also, I find GetWorld()->GetSubsystem() more convenient than putting all the “world” managers as variables in GameState (btw, how you would get a reference to an ActorComponent with World lifetime, if you really need a World-lifetime manager)?

Take into account you might have UEngineSubsystems and UEditorSubsystems, which is harder to achieve with ActorComponents, if possible at all.

At the end of the day, here is the toolbox, and it’s up to developer to use sledgehammer to crack a nut or not.

1 Like
8

funny you mention that because i do have a TimeOfDay manager but again subsystems dont replicate so its useless in my game unless i use another class as intermediary in which case there is no point.

An ActorComponent on the GameState basically matches the world lifetime so thats not an issue.

1 Like