Major blind spot in my understanding of Systems within C++ and Unreal...

Hi All!

Getting to an overly confident stage of my C++ learning where I’m feeling invincible so I came here for some humbling knowledge/advice.

I have a basic question about where/how to hold overarching systems within my game that isn’t linked to a specific in-world object. I am making a playback system within my game for “instant replays”. My prototype is working like a charm - however I currently have the bulk of the system working within an actor component - and I essentially have a “brain” in my game world (literally just a cube that’s hidden at runtime) that has the component attached. I have to imagine there is a way to have logic run in game without having to be attached to an actor in-world. Am I wrong? Would love some advice as I can only imagine this is a product of my ignorance.

Thanks so much to anyone willing to give me a point in the right direction!

Wow OptimisticMonkey that was fast! Thank you for such a quick response! :smiley:

I will definitely read into this as it will likely circumvent/contain most if not all that I’ll need for my playback system!

However, I imagine there are other systems in the future that I’d want to be able to code that I wouldn’t want hard-linked to an in-world asset. For instance if I wanted to keep track of how often a certain enemy type was randomly generated in order to favor a more “unique” enemy to spawn - or a system to keep track of doors opened or windows smashed in an open world game but wanted to localized logic on said door/window to be destroyed after it’s reached a certain distance from the player. I could list more examples if it would help, but hopefully it’s clearer what I’m hoping to learn about when it comes to CPP and Unreal!


Yes there are 2 global instances you can use to put code in where you might need it on a more global scale.

There is a GameMode instance class you can create that is available per MAP/LEVEL. This GameMode class gets spawned when the map loads in and always exists until you leave the map or close the game. You would make your own c++ game mode then load your map and in the world details panel change the game mode to your game mode.

The other is GameInstance, this is the highest level class you can create, and is available once you launch unreal and exists until unreal closes. For all intents and purposes, this is the most global class that can exist. You would create your custom class c++, then in project settings set it to your new game instance class.

You could also write your plugin as an AActor. An AActor needs to be in the map/level, but it doesn’t need to have a position or visibility. (It sill still have a transform, though.)
E g, you don’t need to write it as a COMPONENT, you can write it as just a plain ACTOR.
The benefit of being an actor is that you get good control over networking/replication. And even replay, assuming you’re using the Unreal replay system, which is based on networking.
One way to think about this is that AActor really is the “general interface” for “things in Unreal engine games.” If your “system” is a thing in a game, it makes some sense to put it there.
And, yes, I agree that AActor absolutely suffers from the “God Object” problem of most mature hierarchical object-oriented systems. That’s something we have to live with.

Consider other systems: Most of them are “a library” that does the code, but also “actors in the world” that activate/configure the system. Navmesh, Lightmass, Audio, … many things work like that.
You can implement your system as a shared library, and have specific actor kinds used for setting up “focus areas” or “points of interest” and have those actors know how to work with the shared library to enable its functionality for this particular level.

I think Subsystems is worth considering. I’m a big fan of them.…ems/index.html
@jwatte are you the jwatte that made the excellent .x importer for XNA? Thanks!

@ViperG Thank you for these references!! I had initially thought these were more variable containers vs logic containers. Seems likely that this is the blind spot I needed some light shed on so MANY thanks :]

@jwatte love the insight you gave on how to approach logic assignment. An actor could likely be the best approach for me for some of the systems I have in mind to implement - considering I do want to keep network replication in mind for some of my upcoming systems! It felt counter intuitive to having these actors present in-game, but now I’m beginning to understand “in-world” is just a representation of what would otherwise be included “in scope” of a regular CPP program :] So thank you!

@Bino Ooooooo! Okay, this is exactly why I decided to post here! All three of you have given me some GREAT tools/leads to explore and solve what approach will be best suited for what I want to accomplish. Subsytems ALSO seem like extremely relevant to what I’m looking to do. Lots more to learn - but I greatly appreciate your advice :smiley:

THANK YOU UNREAL COMMUNITY - So happy to finally be pushing my programming education to the forefront of my efforts atm!


This is a pretty sweet overview of unreal that I recommend checking out plus the author has a few udemy classes that are available online

are you the jwatte that made the excellent .x importer for XNA? Thanks!

Guilty as charged. Glad you liked it :slight_smile: