Systems Architecture Documentation

Systems Architecture is a framework that focuses on modular and scalable game logic.

It rewards using DOD (Data-Oriented-Design) over industry-wide OOP standard for writing game logic to reduce occurrence of common pitfals when doing OOP wrong, by avoiding it as much as possible and by that reducing comprehensive complexity to bare minimum.

In this documentation you will learn best practices for producing modular and scalable game systems that together make complex game features, yet still doesn't require countless hours of organization, production and iteration times in the process of making games.

Systems Architecture is refreshingly simple yet powerful tool to make Unreal Engine game developers Work Smart, Not Hard ^TM and we are gonna achieve that by reducing complexity of codebase and production process to bare minimum!

Ok, enought pretty words - let's dive into how Systems Architecture works and what problems does it solve.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Book

This book covers explanation of Systems Architecture, as well as provides learning materials such as guidelines with best practices to keep your project healthy and your sanity in check, it also provides tutorial showing step-by-step how to use Systems Architecture in your game.

Getting started

Before we jump into the meat of Systems Architecture, let me quickly show you a snippet showcasing how working with Systems looks like in a gist:

Click to unfold code snippet


// Actor componetns are treated as data/tags put on actors, that user reads from
// or writes to, using system queries.
UCLASS(BlueprintType, Blueprintable, Meta = (BlueprintSpawnableComponent))
class EXAMPLE_API UPlayerComponent : public USystemsActorComponent
{
	GENERATED_BODY()
};

UCLASS(BlueprintType, Blueprintable, Meta = (BlueprintSpawnableComponent))
class EXAMPLE_API UEnemyComponent : public USystemsActorComponent
{
	GENERATED_BODY()
};

// System are usually lambdas/functions that process chunks of systems world
// data (it can be querying actor components, managing resources or just
// processing some data - the point is we focus on processing game data, no
// matter its form).
void HuntSystem(USystemsWorld& Systems)
{
	const auto DeltaTime = Systems.GetWorld()->GetDeltaSeconds();

	// Systems Architecture adds an interface over game world that allows us to
	// treat it as database that we can query, also rather than putting logic
	// into each object, we rather perform batched data processing on a set of
	// requested components.
	for (auto& PlayerData : Systems.Query<UPlayerComponent>())
	{
		// Queries always yield tuple with actor that owns components
		// requested for query, in addition to following components.
		auto* PlayerActor = PlayerData.Get<0>();
		const auto PlayerPosition = PlayerActor->GetActorLocation();

		const auto Nearest = Systems
								 .Query<UEnemyComponent>()
								 // Mapping iterator is one of the most commonly used
								 // types of iterators that transform data from one form
								 // to another, usually to get exact information needed
								 // by next iterators in chain, or to just process it and
								 // collect the result.
								 .Map<TTuple<FVector, float>>(
									 [&](const auto& EnemyData)
									 {
										 const auto* EnemyActor = EnemyData.Get<0>();
										 const auto EnemyPosition = EnemyActor->GetActorLocation();
										 const auto Distance = FVector::Distance(PlayerPosition, EnemyPosition);

										 return MakeTuple(EnemyPosition, Distance);
									 })
								 // Finding the nearest enemy based on distance extracted
								 // in previous iteration step.
								 .ComparedBy(
									 [](const auto& A, const auto& B)
									 {
										 const auto DistanceA = A.Get<1>();
										 const auto DistanceB = B.Get<1>();

										 return DistanceA < DistanceB;
									 });

		if (Nearest.IsSet())
		{
			const auto TargetPosition = Nearest.GetValue().Get<0>();
			const auto Direction = (TargetPosition - PlayerPosition).GetSafeNormal();
			const auto Velocity = Direction * 100.0f * DeltaTime;

			PlayerActor->SetActorLocation(PlayerPosition + Velocity);
		}
	}
}

UCLASS()
class EXAMPLE_API UExampleGameInstance : public UGameInstance
{
	GENERATED_BODY()

private:
	virtual void Init() override;
};

void UExampleGameInstance::Init()
{
	Super::Init();

	auto* Subsystem = USystemsSubsystem::Get(GetWorld());
	if (IsValid(Subsystem))
	{
		Subsystem->AcquireSystemsWorld(FName(),
			[&](auto& Systems)
			{
				// Due to how queries are resolved, we need to register all
				// components we might want to query.
				Systems.RegisterComponent<UPlayerComponent>();
				Systems.RegisterComponent<UEnemyComponent>();

				// Persistent systems (ones that will run on every game tick)
				// have to be registered in systems world. There are many types
				// of systems, but commonly used ones are state-less
				// lambda/function systems. System labels
				// ("Hunt") are used for resolving systems dependency graph
				// (user can provide sets of systems that given one has to run
				// before and after).
				Systems.InstallLambdaSystem(HuntSystem, FInstallSystemOptions("Hunt"));
			});
	}
}

Systems Architecture is not an ECS!

This is very important to say upfront:

Although at first glance Systems Architecture API looks somewhat like ECS, it definitely is not one.

There are similarities in both, but ECS do more than treat game as database, and its design choices revolve around best performance possible for massive worlds and making improved productivity and reduction of complexity is a side-effect of that, while Systems Architecture doesn't change much to the Unreal Engine API, rather resuses its parts (like actors and actor components) and only adds an API to enable accessing and processing game world in database-like fashion, making Systems Architecture focusing mostly on ergonomics and reducement of overall complexity.

That doesn't mean Systems Architecture doesn't care about performance - it already makes its internals do as less work as possible, and more optimizations are gonna arrive in further development, but the grand goal is and will be always making Unreal Engine game developers life as easier as possible.

That being said, Systems Architecture took great amount of inspiration from ECS, mostly from Rust ECS-based libraries and game engines that proven over time that database-like DOD approach to game logic is not only viable, but also highly beneficial for faster and easier game development process:

As well as Rust lazy-iterators and channel APIs.

Goals

More Data-Oriented-Design approach to game logic

Most infromation you can find prasing DOD focuses too much on its benefits to game performance with huge worlds. I would safely say that this actually shouldn't be the main thing DOD should be recognized by, there is even more important benefit of thinking in terms of data and data processing rather than communication between objects (OOP) - avoiding common pitfalls when trying to model game systems around Real World Things ^TM.

All game is, is just a bunch of data in memory that gets transformed from one form to another.

When we realize that, we can better and easier solve problems by designing data and game logic that works best together and do as less work as possible, instead of adding lots of usually unnecessary abstraction layers just because we might have a false intuition that representing data and logic in human-readable real world representation somehow will make us understand it better and quicker, while after year of development on each game, we find ourselves struggling with adding, removing or just changing how certain parts of game logic works, slapping hacky solutions here and there just to meet deadlines (we can't remove deadlines but we can reduce complexity).

We all have been through that, and we all promise ourselves we are not gonna make same mistakes again in next project, we just need to "better design how our objects communicate", while making totally new and even more problematic mistakes along the way - we can all agree that this next project is never actually free from mistakes we did last time, they all share same source.

That being said DOD isn't a miracle cure that solves all our problems, it brings its own to the table.

But all these problems revolve around us still trying to slap our (false) intuition about objects communication into problems that do not require these in the first place, us not being able to easily switch our brains from thinking in terms of object communication into thinking in terms of data transformations.

Yes, this takes time to appreciate data, but it pays off eventually with us being able to solve problems right way, not creating workarounds here ant there just to follow tons of abstraction layers requirements.

I hope this book will do its best to speed up switching from OOP to more DOD approach, by showing how to simplify problems without using tons of design patterns.

Flat and deterministic flow of data

Events-based logic approach commonly used in Unreal Engine is great for triggering foreign actions (a.k.a. objects messaging) but has one big flaw - it's not scalable as project grows. This happens because user have very limited control over order of actions happening when using events, and it grows into even bigger problem as dependency graph between parts of event-based logic grows.

Dependency graph in events-based game logic is a set of hidden rules of what action requires what other action to run before and after this one, to make sure objects being communicated have valid and expected state at each point of action execution. Hidden, because these rules emerge over time without user noticing them.

Basically any situation where feature A to run properly, depends on feature B to have a certain data, but that data is provided by feature C and so on, and there is no clear way to determine the order of actions that prepare data for any other feature in all code points related to this problem.

Sometimes it gets even worse when features triggers events that receivers triggers their events and their receivers triggers their events and so on - you can see where i'm going with it, this quickly turns into The Fuck Cascade ^TM of tons of state recalculation along the way in a single point in time, just to keep all objects always have valid state that depends on other game features state. This is clearly unmanageable and requires a lot of refactoring to either remove dependencies between them or to defer operations in time. This is something user usually do not put much thought into, until a really weird bug happen in some place unrelated to the problem.

Ok, so what we can do about it?

Well, flatten dependency graph and put execution of game features in line as much as possible. With that we reduce cognitive complexity to bare minimum, and user can easily manage exact order of actions to make sure state is always valid and do not need to recalculate on each change causing cascade of instant changes in features that depend on it - TL;DR: user can see exact flow of data in one place and that makes it easy to reason about, no need for juggling around the whole codebase.

In case user still wants to send data with events, but keep deterministic events execution, Systems Architecture provides feature called channels which uses polling to get received messages and execute them at the exact moment system needs to, avoiding immediate message execution when broadcasting messages.

There is also another benefit we gain from flat dependency graph, that we will discuss next:

Orthogonal and compact game logic

Quote from Eric Steven Raymond in Art of UNIX programming:

Orthogonality is one of the most important properties that can help make even complex designs compact. In a purely orthogonal design, operations do not have side effects; each action (whether it's an API call, a macro invocation, or a language operation) changes just one thing without affecting others. There is one and only one way to change each property of whatever system you are controlling.

What intrests us game developers from this quote is that when we express game logic in a set of simple work units we can easier reduce (or even remove) dependencies between parts of game logic and that allows us to easily reason about them (small code) and add/change/remove them without much time spend on refactoring (next to none dependencies between game logic parts).

Orthogonal game systems are ones that do not require each other to work (like you remove one and your game still runs), but they together make up bigger feature.

How Systems Architecture helps to achieve that?

Well, it helps by forcing user to think about data transformations instead of object communication. When we do not have to deal with abstractions, what's left is data and how we process that data. That allows to focus on solving actual problem instead of trying to fit it into some design pattern.

Because systems are all about data transformations, and System Architecture provides an ergonomic way for performing these (such as queries over game world and iterators), each system by the nature of data it works on, will keep itself doing only the work it needs and not causing hidden cascades of changes in the world, making every change explicit and intentional.

Simple example would be: instead of having per unit movement that handles input, position change and physics at once, you create separate systems:

input system that collects player input and turns it into input data stored either in a global resource or in some actor component, it depends on what you want to do with this data later.

You should always design your data around what it's gonna be used for, not the other way around!
velocity resolve system that reads input data available for given actor and converts these inputs into velocity change and stores it in velocity component.
position change system that reads velocity and applies it to unit position.

You might think: "ok, but this particular example seems to be an easy task that can be just executed all in one place" - and you couldn't be wrong more.

Look at the bigger picture - few months later you'll need to extend or replace physics, or you would need to add another physics resolvers that work on unit velocity and at that point this code gets bigger. You obviously split it into smaller methods, but now designers wants you to let them parameterize or even disable some of its parts at will - well, hello Refactor Tractor ^TM my old friend. If you split these into smaller batched work units, you gain both easy way to toggle each stage of movement and even be able to quickly change or even remove/replace with brand new ones, not to mention being able to quickly add parameterization for designers in matter of minutes to hour, not days.

Like i said before:

Keeping systems small makes it easy to reason about them and that is a one huge productivity booster that you'll love to still have after year of development on your game.

Modularity and reusability

Modularity, which means we can build complex features from smaller building blocks, gives us an ability to reuse or even share these modules with other developers (free or paid, on github or marketplace). In companies it is even more important to share and reuse certain modules between different teams and products, as demand for making more by doing less grows as company structure and portfolio grows.

Systems Architecture, by its design, allows to put generalized systems and components into separate modules, with none (or sometimes next to none) dependencies between other parts of the game. Are you making a simulation game with NPCs wandering around on the map in one project, then in next one you need to make them too? Put these in a module or just migrate them to another project. Code that doesn't compile? Fear no more, you have got decoupled systems at the moment you've started making them, there is next to none work needed after migration, just register systems into pipeline and slap these components on actors and run the game.

For indies and Unreal Engine plugin creators there are also great news!

Systems Architecture core design, when treated as platform/framework, enables Unreal Engine plugin developers to finally create an ecosystem of plugins trully compatible with each other. Ecosystem of compatible plugins that do not require a hussle of installation steps, makes plugins more accessible for users that want game features that Just Works ^TM and creates opportunity for more sales for plugin devs - this is a big win for both worlds, users and creators.

And as a bonus:

System Architecture is and will always remain free under permissive licenses, for anyone, accepting reasonable contributions that improve its ergonomics, quality and performance.

Conclusions

If you should take anything from this, remember:

When making games, you're basically just processing data and you don't need fancy distraction-abstractions for that.

Make it flat
Make it small
Make it compact and disconnected from other systems

Then you'll keep your sanity after year of development on a single game title.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Architecture

This section will explain in-depth how Systems Architecture exactly works and how to abuse it to solve your problems the right way.

Systems Architecture adds a database-like interface over game world to allow ergonomic queries for game world data processing.

Actor components should only store data

Or no data, if they are considered tags, used as markers over actors. Tags such as UEnemyComponent that enables this actor to be queried in systems that works on enemies.

And sometimes methods, but only these that do not have side effects reaching outside of this actor component scope - the point is: it's systems job to perform game logic, actor component methods should at most contain methods that recalculate their internal state, and these are operations called in more than one place.

This rule gets invalidated for situations like actor component being a bridge to some Unreal Engine built-in components or third-party code to which handles are stored in actor components. Just make sure your own actor components do as less work as possible.
Systems do most if not all game logic

This means whenever you want to put some commonly used piece of logic in actor component or (gods forbid) in actor, make a system for it.

It will pay off months later by still having small orthogonal game systems with as less dependencies as possible, systems that can be easily toggled, changed or even removed/replaced - no more hours or days of careful code refactoring just because you need to change or remove some bit of game feature.

Your game world is just a database

Systems Architecture gives you ergonomic tools to ease work on batched sets of actor components using game world queries.

UCLASS()
class BOIDS_API UBoidsMovementSystem : public USystem
{
	GENERATED_BODY()

public:
	virtual void Run(USystemsWorld& Systems) override;
};

void UBoidsMovementSystem::Run(USystemsWorld& Systems)
{
	Super::Run(Systems);

	const auto* BoidsSettings = Systems.Resource<UBoidsSettings>();
	if (IsValid(BoidsSettings) == false)
	{
		return;
	}
	const auto TimeScale = BoidsSettings->TimeScale;
	const auto DeltaTime = Systems.GetWorld()->GetDeltaSeconds() * TimeScale;

	for (auto& QueryItem : Systems.Query<UVelocityComponent, UBoidComponent>())
	{
		auto* Actor = QueryItem.Get<0>();
		const auto* Velocity = QueryItem.Get<1>();
		const auto Position = Actor->GetActorLocation();

		Actor->SetActorLocation(Position + Velocity->Value * DeltaTime);
	}
}

With queries you have all this system logic in one place - that greatly reduces comprehensive complexity, no more need to jump around whole codebase just to understand how system works, and we make ourselves keep systems small, doing only only the work they need and no other.

Pages

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

World

Explanation

USystemsWorld is a registry that stores systems, resources and actor components. The first thing you do is you setup your systems world by installing systems, resources and registering actor components that will be used in systems queries to process and do something useful with resources and actor components.

UCLASS()
class EXAMPLE_API UExampleGameInstance : public UGameInstance
{
	GENERATED_BODY()

private:
	virtual void Init() override;
};

void UExampleGameInstance::Init()
{
	Super::Init();

	auto* Subsystem = USystemsSubsystem::Get(GetWorld());
	if (IsValid(Subsystem))
	{
		Subsystem->AcquireSystemsWorld(FName(),
			[&](auto& Systems)
			{
				Systems.RegisterComponent<UShiaComponent>();

				Systems.InstallResource<UShiaSettings>();

				Systems.InstallLambdaSystem(JustDoItSystem, FInstallSystemOptions("JustDoIt"));
			});
	}
}

In example above we register systems world in game instance. We can of course create systems worlds at will without registering it into USystemsSubsystem, this global registry is only a more convenient way to access and automate systems world management globally.

Once per tick (when using subsystem approach) all systems gets to run in order they were installed (system installation options can provide additional hints about more precise order when working with dependencies between systems).

Queries

The whole point of Systems Architecture is to process game world in a database-like fashion, which means to perform same operations on a batched set of actor components, instead of putting that work into these objects. That makes us completely decouple data from behaviors, making it easier to add, remove and change them at will, even reuse without dealing with solving hidden dependency tree problems between seemingly unrelated parts of codebase.

	const auto Count = static_cast<int>(Systems.Query<UBoidComponent>().Count());
	const auto Difference = Count - EXPECTED_POPULATION_NUMBER;

	if (Difference > 0)
	{
		for (auto& QueryItem : Systems.Query<UBoidComponent>().Take(Difference))
		{
			auto* Actor = QueryItem.Get<0>();
			Actor->Destroy();
		}
	}

Queries are iterators that always yields a tuple of actor components and can be chained with other iterators to produce more elaborated, yet easy to reason about data transformations. For example when you do Systems.Query<A, B, C>, values yielded by query iterator will be of type TTuple<AActor*, A*, B*, C*>. it's also important to note that user should never cache query objects, rather consume queries in place.

See TQuery.

Archetypes

Internally all actor components are stored in buckets called archetypes. Given actor archetype is determined by its FArchetypeSignature, which is calculated from the set of components given actor owns. When actor registers its components, systems world searches through already existing archetypes and if it finds one, actor gets registered in that bucket, if not new archetype bucket gets created.

The point of storing actors in groups per archetype is to make queries iteration as fast as possible by iterating over only these actors that own all requested components in a linear fashion without need for skipping over actors that we don't need to work on.

Archetype signatures are basically bitsets of 256 bits capacity, each bit represents registered actor component. Whenever signature gets calculated for given query, it makes empty signature and enables bits for requested component, then it compares this signature with each archetype bucket signature and stores in query object a list of archetypes to iterate on.

Problems that it solves

Usually when working with game managers it's a common practice to cache managers in other managers to not perform costly searches in game world. This is unnecessary work and Systems Architecture solves that by storing resources in single systems world, easily accessible from any system without any need for caching any used resources in systems itself.

Another common problem is usually hierarchy of game logic gets growing in depth, like when game logic is performed by game objects themselves, they reference one another, growing hidden dependency tree and by that comprehensive complexity that requires sometimes hours to jump around whole codebase just to understand how data flows between certain objects. Systems Architecture forces user to make flat game logic with explicit order of execution, additionally making units of work as small and as precise as possible to make it easy to reason about how game data gets processed.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Systems

Explanation

Systems are small but precise units of work, work that's mainly about processing game world data using queries. These queries are processed using iterators, and that makes queries the whole point of systems ergonomics since they simplify both computational and comprehensive complexity and make that part of game logic really easy to reason about, which in turn makes adding, removing and changing game logic easy and quicker than with monolithic code or features highly dependent on each other, scattered around the codebase.

Types of systems

There are few types of systems, but the ones that you will mostly use are stateless (lambdas/functions) and stateful (classes) systems.

Stateless systems

These are the most common ones. Stateless systems are just lambdas/functions that expect reference to USystemsWorld to operate on it. Stateless systems do not require any internal state to operate.

void MovementSystem(USystemsWorld& Systems)
{
	const auto* Settings = Systems.Resource<USettings>();
	if (IsValid(Settings) == false)
	{
		return;
	}
	const auto TimeScale = Settings->TimeScale;
	const auto DeltaTime = Systems.GetWorld()->GetDeltaSeconds() * TimeScale;

	for (auto& QueryItem : Systems.Query<UVelocityComponent>())
	{
		auto* Actor = QueryItem.Get<0>();
		const auto* Velocity = QueryItem.Get<1>();
		const auto Position = Actor->GetActorLocation();

		Actor->SetActorLocation(Position + Velocity->Value * DeltaTime);
	}
}

void UExampleGameInstance::Init()
{
	Super::Init();

	auto* Subsystem = USystemsSubsystem::Get(GetWorld());
	if (IsValid(Subsystem))
	{
		Subsystem->AcquireSystemsWorld(FName(),
			[&](auto& Systems)
			{
				Systems.RegisterComponent<UVelocityComponent>();

				Systems.InstallLambdaSystem(MovementSystem, FInstallSystemOptions("Movement"));
			});
	}
}

Stateful systems

Stateful systems are useful in cases where system requires some internal state that cannot be shared with other systems via resources (for example internal cache that is used to track changes in the system across multiple game ticks).

UCLASS()
class EXAMPLE_API ULogBirdsNumberChangeSystem : public USystem
{
	GENERATED_BODY()

public:
	virtual void Run(USystemsWorld& Systems) override;

	UPROPERTY()
	uint32 LastCount = 0;
};

void ULogBirdsNumberChangeSystem::Run(USystemsWorld& Systems)
{
	Super::Run(Systems);

	if (Systems.ComponentsDidChanged<UBirdComponent>() == false)
	{
		return;
	}

	const auto Number = static_cast<int>(Systems.Query<UBirdComponent>().Count());
	const Difference = Number - this->LastCount;
	this->LastCount = Number;

	if (Difference > 0)
	{
		UE_LOG(LogTemp, Warning, TEXT("Added %i birds"), Difference);
	}
	else if (Difference < 0)
	{
		UE_LOG(LogTemp, Warning, TEXT("Removed %i birds"), -Difference);
	}
}

void UExampleGameInstance::Init()
{
	Super::Init();

	auto* Subsystem = USystemsSubsystem::Get(GetWorld());
	if (IsValid(Subsystem))
	{
		Subsystem->AcquireSystemsWorld(FName(),
			[&](auto& Systems)
			{
				Systems.RegisterComponent<UBirdComponent>();

				Systems.InstallSystem<ULogBirdsNumberChangeSystem>(FInstallSystemOptions("LogBirdsNumberChange"));
			});
	}
}

Problems that it solves

There is very common (bad) practice in the industry that we make a game prototype, then we build actual game on top of that prototype codebase, instead of treating it purely as a reference for an actual, properly implemented solutions in actual project - this can and will quickly lead to poisoned codebase months and years later. It is really hard to break that habit, mostly in professional game development because time budget and famous last words such as "we will refactor that later", but that "later" do not come as soon as we would like, making us having a weak foundation and we build new features on top of that weak foundation, basically playing Jenga with our codebase, codebase which parts of will fall later as the project grows, causing The Fuck Cascade ^TM. and frustration later on - we can do better than that.

Systems Architecture helps with that by forcing simple and modular codebase from the get go, making switching from prototype to actual implementation a matter of just swapping prototype systems with actual properly implemented systems, sometimes not even having to change them at all.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Components

Explanation

See USystemsActorComponent and USystemsSceneComponent.

Systems Architecture treats game world as database that user can query. That enables us to perform same operations on a batch of actors and their requested components in-place.

	const auto Count = static_cast<int>(Systems.Query<UBoidComponent>().Count());
	const auto Difference = Count - EXPECTED_POPULATION_NUMBER;

	if (Difference > 0)
	{
		for (auto& QueryItem : Systems.Query<UBoidComponent>().Take(Difference))
		{
			auto* Actor = QueryItem.Get<0>();
			Actor->Destroy();
		}
	}

And all you have to do is to add or remove components on your actors of interest to enable/disable them for certain systems, instead of juggling or even duplicating code around many classes, growing your hidden dependency graph. That simplifies the game logic and greatly improves iteration times on game systems.

Keeping data decoupled from game logic enables you to easily perform different logic on same set of data, avoiding duplication of both logic and data, making it easier to iterate on them.

Of course sometimes keeping some logic in components is reasonable - good practice is to add into actor components only these methods that do not produce any side effects outside this component scope, which means logic that only serves to recalculate its internal state.

Problems that it solves

When working with Unreal Engine, mostly as a beginner, a little bit less as an advanced user, you find yourself slapping a lot of code into actors. The general thought wandering around your mind at that time usually goes like this: "This code is something that only this actor does, so it's obvious that this code belongs to this actor class, duh" - at that time, while there is still not much work put in there you might be right, but in that case your intuition is wrong once again.

Across next months you slap bits of logic there and its complexity grows. It doesn't help that you've split it into several methods, all of that effort gets invalidated once you have to add a second, and a third actor that does similar things, and you suddenly find yourself redesigning proper decoupling or inheritance tree or even doing massive refactoring because this one problem touches many seemingly unrelated places, that were part of complex hidden dependency tree.

All of that could be avoided with splitting monolithic work per components, but we can do even better and completely decouple data from logic that we put in small dedicated systems.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Resources

Explanation

Resource in context of Systems Architecture is any global object that all systems should be able to access (though resources definitely aren't singletons! - they share their lifetime with owning systems world). Objects such as:

Configuration/settings data

For example systems run criteria that tells the conditions under what certain systems can run. Or Data Assets / Data Tables passed from game instance to systems world.
Cached data shared between systems

Do you have spatial partitioning system that builds RTree for world actors to speed up spatial queries, and other systems in need to find the closest actor to their location? You definitely put that data in a resource object and make other systems query and read that resource!
Game managers

Common Unreal Engine game development pattern is to create work units called "managers" that manage certain state. For some solutions, especially when dealing with third-party plugins, we have to still have access into these managers in our systems - definitely put them in systems world resources.

UCLASS(BlueprintType)
class EXAMPLE_API USettings : public UDataAsset
{
	GENERATED_BODY()

public:
	UPROPERTY(EditAnywhere)
	float TimeScale = 1;
};

void UExampleGameInstance::Init()
{
	Super::Init();

	auto* Subsystem = USystemsSubsystem::Get(GetWorld());
	if (IsValid(Subsystem))
	{
		Subsystem->AcquireSystemsWorld(FName(),
			[&](auto& Systems)
			{
				Systems.RegisterComponent<UVelocityComponent>();

				// USettings asset set up in editor.
				Systems.InstallResourceRaw(this->Settings);

				Systems.InstallLambdaSystem(MovementSystem, FInstallSystemOptions("Movement"));
			});
	}
}

void MovementSystem(USystemsWorld& Systems)
{
	const auto* Settings = Systems.Resource<USettings>();
	if (IsValid(Settings) == false)
	{
		return;
	}
	const auto TimeScale = Settings->TimeScale;
	const auto DeltaTime = Systems.GetWorld()->GetDeltaSeconds() * TimeScale;

	for (auto& QueryItem : Systems.Query<UVelocityComponent>())
	{
		auto* Actor = QueryItem.Get<0>();
		const auto* Velocity = QueryItem.Get<1>();
		const auto Position = Actor->GetActorLocation();

		Actor->SetActorLocation(Position + Velocity->Value * DeltaTime);
	}
}

Proxy Resources

Along the journey you might find yourself in a need for having to use wrapper-like resources that themselves are not unique types but they wrap unique type resource - wrappers/containers for some inner data. For that scenario you will use concept called Proxy Resources, which allows you to install resource wrapper, which of type itself is not used, instead you provide its inner type used for queries.

First we define proxy resource:

UCLASS()
class EXAMPLE_API UInventoryWrapper : public UDataAsset
{
	GENERATED_BODY()

public:
	UPROPERTY()
	UInventory* GeneratedInventory = nullptr;
};

Then we install it in Systems World:

auto* Wrapper = NewObject<UInventoryWrapper>(Systems, UInventoryWrapper::StaticClass());
Systems.InstallProxyResource<UInventory>(Wrapper, [](auto* Wrapper) { return Wrapper->GeneratedInventory; });

And finally we access it:

Systems.ProxyResource<UInventory>()->AddItem(FItem{FItemType::Sword});

Problems that it solves

While in most cases all what you do is you process game world queries, sometimes you require to access some configuration data, or cache some data for use by many other systems, or you just need to interact with third-party game managers - these are useful use cases and Systems Architecture doesn't get rid of them, rather make their use more ergonomic, yet not giving them global lifetime like with dangerous singletons.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Subsystem

Explanation

For the sake of convenience Systems Architecture provides handy wrapper over USystemsWorld global instances as a USystemsSubsystem that is basically a registry of systems worlds accessible from any place in the code.

All user needs to do is to register and setup systems world using USystemsSubsystem::AcquireSystemsWorld when certain game phase starts (either game, level, menu, etc) before adding/removing/querying actor components, and unregister systems world using USystemsSubsystem::ReleaseSystemsWorld when given game phase ends.

Examples

The most common game phases where systems might exists are game instance and game mode.

You register systems world in game instance when there are systems are possible to run during entire game lifetime. This is the easiest and safest option.
You register systems world in game mode when there are systems that are possible to run during given game level lifetime. This is useful if we for example have completely separate pipelines set for each level or game mode.

Game instance

Since game instance has a lifetime of entire game run, we only care here about registering systems world to subsystem on UGameInstance::Init.

UCLASS()
class EXAMPLE_API UExampleGameInstance : public UGameInstance
{
	GENERATED_BODY()

private:
	virtual void Init() override;
};

void UExampleGameInstance::Init()
{
	Super::Init();

	auto* Subsystem = USystemsSubsystem::Get(GetWorld());
	if (IsValid(Subsystem))
	{
		Subsystem->AcquireSystemsWorld(FName(),
			[&](auto& Systems)
			{
				Systems.RegisterComponent<UShiaComponent>();

				Systems.InstallResource<UShiaSettings>();

				Systems.InstallLambdaSystem(JustDoItSystem, FInstallSystemOptions("JustDoIt"));
			});
	}
}

Game mode

When it comes to game mode, we should register systems world on AGameModeBase::InitGame (it runs before any actor BeginPlay - if we register it on BeginPlay, then some actors placed on level might try to register to yet non-existing systems world) and unregister it on AGameModeBase::EndPlay.

UCLASS()
class EXAMPLE_API AExampleGameMode : public AGameModeBase
{
	GENERATED_BODY()

private:
	virtual void InitGame(const FString& MapName, const FString& Options, FString& ErrorMessage) override;

	virtual void EndPlay(const EEndPlayReason::Type EndPlayReason) override;
};

void AExampleGameMode::InitGame(const FString& MapName, const FString& Options, FString& ErrorMessage)
{
	Super::InitGame(MapName, Options, ErrorMessage);

	auto* Subsystem = USystemsSubsystem::Get(GetWorld());
	if (IsValid(Subsystem))
	{
		Subsystem->AcquireSystemsWorld(FName(),
			[&](auto& Systems)
			{
				Systems.RegisterComponent<UShiaComponent>();

				Systems.InstallResource<UShiaSettings>();

				Systems.InstallLambdaSystem(JustDoItSystem, FInstallSystemOptions("JustDoIt"));
			});
	}
}

void AExampleGameMode::EndPlay(const EEndPlayReason::Type EndPlayReason)
{
	Super::EndPlay(EndPlayReason);

	auto* Subsystem = USystemsSubsystem::Get(GetWorld());
	if (IsValid(Subsystem))
	{
		Subsystem->ReleaseSystemsWorld(ThisClass::SYSTEMS_WORLD);
	}
}

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Pipelines

Explanation and setup

See USystemsPipeline.

Systems pipeline is a data asset that describes configuration of a single systems world: its components, resources and systems that should be installed for new systems world. Given pipeline is then assigned to either ASystemsGameMode or ASystemsGameState to automatically create and destroy dedicated systems world.

Having systems pipeline defined in a data asset simplifies systems world setup and gives more flexibility to game designers so they can balance and test special cases and new game features without asking programmers to take their time and make changes to the setup.

Data Asset

World Id - ID under which this pipeline systems world will be registered globally. Usually there is gonna be single systems world so it's best to leave None here, but in rare cases there might be sometimes a need to for multiple systems worlds in the game at once so here user can specify that.

Components

See components architecture book page.

List of all component types that are gonna be recognized by this systems world.

Components

Development Build Only - Ensures this component will be registered in development builds only (and editor builds).
Use - Useful for quickly disabling given component from the pipeline without actually removing it, can be used for quick dirty tests.

Resources

See resources architecture book page.

Type resources

List of type resources to install.

Type resources are usually just a typical UObject-based game managers, 3rd-party library wrappers, data shared runtime data cache/storage and such.

Type Resources

Use Global Storage - Makes this resource transferable from one pipeline to another, to achieve shared resources. For example if main menu pipeline has User Info resource to fill its user name, game pipeline will obtain exactly the same resource instead of creating new one, to use previously filled user name in the game.
Development Build Only - Ensures this resource will be registered in development builds only (and editor builds).
Use - Useful for quickly disabling given resource from the pipeline without actually removing it, can be used for quick dirty tests.

Asset resources

List of asset resources to install.

Asset resources are purely data (either baked data sources or systems settings) that will be used by systems.

Asset Resources

Proxy - Marks this resource as proxy with custom inner resource unpacker USystemsPipelineProxyResource.
Development Build Only - Ensures this resource will be registered in development builds only (and editor builds).
Use - Useful for quickly disabling given resource from the pipeline without actually removing it, can be used for quick dirty tests.

Systems

See systems architecture book page.

Here we list all of the systems that are gonna be used by this pipeline's systems world.

Order of systems in the list represents order of their execution!

Systems

Template - Template USystem-based object that can be configured in-place.
Development Build Only - Ensures this system will be registered in development builds only (and editor builds).
Use - Useful for quickly disabling given system from the pipeline without actually removing it, can be used for quick dirty tests.

Note the difference between category of systems:

Startup - Runs only at systems world installation.

Persistent - Runs on every game frame.

Cleanup - Runs only at systems world uninstallation.

Commonly used template types:

Stateful systems

Stateful systems are ones that can have configuration properties put in them and/or can hold internal state (for example to cache some values between next system runs, change detection for example). User makes them by inheriting directly from USystem class.

Stateless systems

Stateless systems are basically lambdas/functions registered into FSystemsReflection.

Lambda Systems

The reason for lambda systems to be registered is that Unreal doesn't come with it's own global function reflection so we have to put these into a dedicated registry ourselves, so we can assign them in ULambdaSystem's Function Name property.

Every game or plugin module that exposes its lambda systems, has to register them in module StartupModule and ShutdownModule methods like this:

#include "Tutorial.h"

#include "Systems/Public/SystemsReflection.h"

#include "Tutorial/Systems/Persistent/TutorialGoToSystem.h"
#include "Tutorial/Systems/Persistent/TutorialMoveTowardsTargetSystem.h"
#include "Tutorial/Systems/Persistent/TutorialMovementSystem.h"
#include "Tutorial/Systems/Persistent/TutorialSelectActorsSystem.h"

#define LOCTEXT_NAMESPACE "FTutorialModule"
#define SYSTEMS_NAMESPACE "Tutorial"

void FTutorialModule::StartupModule()
{
	REGISTER_SYSTEM_FUNCTION(TutorialGoToSystem);
	REGISTER_SYSTEM_FUNCTION(TutorialMoveTowardsTargetSystem);
	REGISTER_SYSTEM_FUNCTION(TutorialMovementSystem);
	REGISTER_SYSTEM_FUNCTION(TutorialSelectActorsSystem);
}

void FTutorialModule::ShutdownModule()
{
	UNREGISTER_SYSTEM_FUNCTION(TutorialGoToSystem);
	UNREGISTER_SYSTEM_FUNCTION(TutorialMoveTowardsTargetSystem);
	UNREGISTER_SYSTEM_FUNCTION(TutorialMovementSystem);
	UNREGISTER_SYSTEM_FUNCTION(TutorialSelectActorsSystem);
}

#undef LOCTEXT_NAMESPACE
#undef SYSTEMS_NAMESPACE

IMPLEMENT_GAME_MODULE(FTutorialModule, Tutorial);

Blueprint systems

Blueprint systems are systems made for quick and dirty prototyping by technical designers and content creators, they serve purely as final reference for programmers to translate them into native C++ systems. They exists exactly for scenarios where technical designer or content creator has an idea for a game feature they want to quickly make and test its viability, without bothering programmers to put their hands into every aspect of it, making feature design phase much faster and removing every back-and-forth between programmers and idea owners.

Blueprint systems are made up of two objects:

Query blueprint with public properties that represents what components (and optionally actor) query expects to iterate on.
System blueprint with OnRun event that performs one or more queries on systems world.

Here is example of creating blueprint systems:

Create new game object that inherits from UObject:

And name it BP_ShakeSystemQuery.
Create public properties of actor/scene component types (and optionally an actor) your system query wants to iterate on:
Create new game object that inherits from UScriptableSystem:

And name it BP_ShakeSystem.
Create System World Query node and assign BP_ShakeSystemQuery object class:

With this we tell tis query iterator it will yield BP_ShakeSystemQuery objects with requested components and actor assigned to its fields.
Create Lazy Iterate node:

Since Query returns a lazy iterator object (you can read about lazy iterators in this architecture book page), this node is a For Each equivalent, to iterate over this iterator elements.
Apply changes to actor offset component we got from yielded query object:

Using pipeline data assets

While you can call USystemsPipeline::Install and USystemsPipeline::Uninstall directly to install and uninstall given pipeline systems world globally, it is useful to have that automated, and for that these are game objects that do this for you, based on pipeline data asset assigned to them in the editor:

Systems game mode

See ASystemsGameMode.

Consider using it to install pipeline that has to run singleplayer or multiplayer server game logic (since game modes are spawned only there).

Create game mode that inerits from ASystemsGameMode:

And name it BP_TutorialGameMode.
Assign USystemsPipeline data asset into Systems Pipeline property:

Systems game state

See ASystemsGameState.

Consider using it to install pipeline that has to run multiplayer client game logic (internally it will enforce to install only on multiplayer client).

Create game state that inerits from ASystemsGameState:

And name it BP_TutorialGameState.
Assign USystemsPipeline data asset into Systems Pipeline property:
Additionally you assign this game state class in its sibling game mode:

To make server game mode spawn this game state with its pipeline on clients.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Iterators

Explanation

Iterators, or more precisely lazy iterators, are an useful tool for more efficient and ergonomic processing of collections and procedural generators. Lazy iterators are lazy because on their own they do not yield any values until consumed.

// [0.0, 4.0, 16.0, 36.0, 64.0]
const TArray<float> Result = IterRange(0, 10)
								 .Filter([](const auto& Value) { return Value % 2 == 0; })
								 .Map<float>([](const auto& Value) { return static_cast<float>(Value * Value); })
								 .CollectArray();

This lazyness allows us to produce more elaborated processing over data without making unnecessary caching between iteration stages, and that also makes iteration code cleaner and easier to reason about.

Types of iterators

Consumers

Consumers are final iterators that consume yielded values and produce some result out of it, usually single value.
```
// 5
const TOptional<int> Result = IterRange(0, 10).Find([](const auto& Value) { return Value >= 5; });
```
Colectors

Collectors are special kind of consumer iterators that are an explicit way to collect all yielded values into commonly used collections such as TArray, TSet and TMap.
```
const TArray<int> Result = IterRange(0, 10).CollectArray();
```
- TQuery::CollectArray
- TQuery::CollectIntoArray
- TQuery::CollectSet
- TQuery::CollectIntoSet
- IterCollectMap
- IterCollectIntoMap
Converters

Converters are stages of iteration that converts values yielded by previous iteration stages into some new values.
```
// [0.0, 4.0, 16.0, 36.0, 64.0]
const TArray<float> Result = IterRange(0, 10)
								 .Filter([](const auto& Value) { return Value % 2 == 0; })
								 .Map<float>([](const auto& Value) { return static_cast<float>(Value * Value); })
								 .CollectArray();
```

Creating custom iterators

While built-in iterators provided by SystemsArchitecture should be enough for common usecases, sometimes for more advanced solutions you might find yourself in a need of creating a custom iterator that cannot be solved using built-in ones.

Anatomy if iterators

Let's take a look at Repeat iterator:

#pragma once

#include "CoreMinimal.h"

// Make sure to include converters declaration header first.
#include "Systems/Public/Iterator/ConvertersDecl.h"

// Then converters, macros and size hint, order doesn't matter here.
#include "Systems/Public/Iterator/Converters.h"
#include "Systems/Public/Iterator/Macros.h"
#include "Systems/Public/Iterator/SizeHint.h"

// This iterator is generalized over type of values it yields.
template <typename T>
struct TIterRepeat
{
public:
	// We need to provide type aliases for iterators injected with macros will
	// properly understand this iterato when wrapping it internally.
	using Self = TIterRepeat<T>;
	using Item = typename T;

	TIterRepeat() : Value(TOptional<T>())
	{
	}

	TIterRepeat(T Data) : Value(TOptional<T>(Data))
	{
	}

	// Provide `Next` method that returns optional value of item type.
	TOptional<Item> Next()
	{
		return TOptional<T>(this->Value);
	}

	// Provide `Sizehint` method thar returns hint about estimated range of
	// items it can yield.
	IterSizeHint SizeHint() const
	{
		return IterSizeHint{0, TOptional<uint32>()};
	}

private:
	TOptional<T> Value = {};

public:
	// To make iterators chains we call special macro that injects all other
	// built-in iterators as this one methods.
	ITER_IMPL
};

// Provide handy construction function for ergonomics, just because of C++
// having easier times with types deduction on them.
template <typename T>
TIterRepeat<T> IterRepeat(T Value)
{
	return TIterRepeat<T>(Value);
}

Self type alias

Iterators chaining is done by wrapping consecutive iterators in one another so when consumer calls Next, it internally calls Next of iterator it wraps, and so on. To make them easily injectable with macros, they use Self as an alias for their type.
Item type alias

Type alias for type of value that this iterator yields. Not stores, not takes as an input - exactly one that it yields. This is again used for iterators wrapping purposes so converter iterators that wraps other iterators can identify value type of previous one in chain by typename ITERATOR::Item.
Next method

Every iterator should implement TOptional<Item> Next() method. This method does the actual job of yielding a value.

See TQuery::Next.
SizeHint method.

Size hints are used by for example collector iterators to estimate the capacity of collection where yielded data will be stored. This at most removes reallocations when adding every next value into that collection, and at least reduces it to some reasonable number.

Finite iterators will give lower bounds and upper bounds set, infinite iterators will give only lower bounds.

See TQuery::SizeHint, IterSizeHint.
ITER_IMPL macro

This macro injects other iterators as methods of this one. Without it user would be left with ugly iterators chains made by passing next stages as argument to iterator functions/constructors.

Iterator adapters

In some rare cases you might find yourself struggling to express your data processing with built-in iterators, or you must to make some optimizations that cannot be solved using provided ones. For this advanced usecase you can create custom iterator adapters that works basically the same way as converter iterators.

template <typename T>
struct TIterOddAdapter
{
public:
	template <typename I>
	TOptional<T> Next(I& Iter)
	{
		Iter.Next();
		return Iter.Next();
	}

	template <typename I>
	IterSizeHint SizeHint(const I& Iter) const
	{
		return Iter.SizeHint();
	}
};

// [1, 3, 5, 7, 9]
const TArray<int> Result = IterRange(0, 10).Adapt(TIterOddAdapter<int>()).CollectArray();

They differ from regular iterators in a way that they do not need type aliases and their Next and SizeHint methods require reference to previous stage iterator so they both consume and process its yielded values.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Channels

Explanation

See TSenderChannel, TReceiverChannel.

Shared channels are Single-Produce, Multiple-Consumer events that instead being executed at the time of sending message (pushing), they are executed at the time of receiving, which is an on-demand operation - user decides when to read messages received in event.

	auto Sender = TSenderChannel<int>();
	auto Receiver = Sender.Receiver(1);

	Sender.Send(42);
	while (const auto Value = Receiver.Receive())
	{
		UE_LOG(LogTemp, Warning, TEXT("Received value: %i"), Value);
	}

Internally channels work as a ring buffer behind thread-safe shared pointer in receiver channel, and sender channel only holds a weak pointer to list of registered receivers. When you want to subscribe to a channel, you create a receiver and store that receiver somewhere.

It's important to note that receiver is bound to a sender channel as long as it exists, so there is no need for intentional unbinds, it is all automated by its design.

After you have sender and receivers made, when you tell sender channel to send message, it goes through all weak pointers pointing to receiver channels, and write cloned data into each of their queues. Messages are stored, but not yet executed.

When you want to receive and execute a message, just make receiver read sequence of next messages in queue and do something useful with them. That's all, simple isn't it?

Problems that it solves

There is only one but big problem that it solves - making more deterministic and ordered data flow between parts of game logic. That way we avoid situations where objects communicating with each other are dependend on proper order of messages being sent and received but we can't ensure that order. We also avoid event cycles, where there is set of event points that suddenly gets connected in a way that introduces a cycle of passing messages, leading to game freezes/crashes due to stack overflow, or simply just situations where some data gets passed too early and invalidates dependent object state causing unnecessary state recalculations later by other objects trying to get some data out of it.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Learning materials

List of learning materials that showcase common and special case usage of Systems Architecture.

Pages

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Tutorial

Here we will showcase step-by-step process of basic usage of Systems Architecture - both for C++ and Blueprint usage scenarios.

Pages

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Installation

Until plugin gets accepted to Unreal Engine Marketplace, we need to install plugin from GitHub.

Download plugin from GitHub Release page (core plugin is in Systems-Architecture.zip archive file).
Make sure project folder structure contains Plugins folder in its root (next to Content and Source folders), then unzip its content into Plugins folder.
Launch editor and confirm plugin is properly added by trying to create new data asset of USystemsPipeline type:

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Setup component

C++

Tutorial/Components/TutorialMovementComponent.h:

#pragma once

#include "CoreMinimal.h"

#include "Systems/Public/SystemsComponent.h"

#include "TutorialMovementComponent.generated.h"

UCLASS(BlueprintType, Blueprintable, Meta = (BlueprintSpawnableComponent))
class TUTORIAL_API UTutorialMovementComponent : public USystemsActorComponent
{
    GENERATED_BODY()

public:
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    FVector Value = FVector(0);
};

Tutorial/Components/TutorialMovementComponent.cpp:

#include "Tutorial/Components/TutorialMovementComponent.h"

Blueprint

Create new game object that inherits from USystemsActorComponent:

And name it BP_TutorialMovement.
Add Value property of Vector type:

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Setup actor

Create new game object that inherits from ASystemsActor or Actor (if you don't need automatic built-in engine components registration based on Systems tag) - same for pawns (ASystemsPawn or Pawn):

And name it BP_Entity.
Add BP_TutorialMovement component:
Assign random unit vector to TutorialMovement::Value on BeginPlay event:

To initially pick a random direction for this actor further movement.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Setup system

C++

Tutorial/Systems/TutorialMovementSystem.h:

#pragma once

#include "CoreMinimal.h"

class USystemsWorld;

UFUNCTION()
void TUTORIAL_API TutorialMovementSystem(USystemsWorld& Systems);

Tutorial/Systems/TutorialMovementSystem.cpp:

#include "Tutorial/Systems/Persistent/TutorialMovementSystem.h"

#include "Systems/Public/SystemsWorld.h"

#include "Tutorial/Components/TutorialMovementComponent.h"

void TutorialMovementSystem(USystemsWorld& Systems)
{
    const auto DeltaTime = Systems.GetWorld()->GetDeltaSeconds();

    Systems.Query<UTutorialMovementComponent>().ForEach(
        [&](auto& QueryItem)
        {
            auto* Actor = QueryItem.Get<0>();
            auto* Movement = QueryItem.Get<1>();
            const auto Position = Actor->GetActorLocation();
            const auto Velocity = Movement->Value * DeltaTime;

            Actor->SetActorLocation(Position + Velocity);
        });
}

Since this is a lambda system, we need to register it to FSystemsReflection. To do that you have to register it in your game module:

Tutorial/Tutorial.h:

#pragma once

#include "CoreMinimal.h"

#include "Modules/ModuleManager.h"

class FTutorialModule : public IModuleInterface
{
public:
    virtual void StartupModule() override;

    virtual void ShutdownModule() override;
};

Tutorial/Tutorial.cpp:

#include "Tutorial.h"

#include "Systems/Public/SystemsReflection.h"

#include "Tutorial/Systems/Persistent/TutorialMovementSystem.h"

#define LOCTEXT_NAMESPACE "FTutorialModule"
#define SYSTEMS_NAMESPACE "Tutorial"

void FTutorialModule::StartupModule()
{
    REGISTER_SYSTEM_FUNCTION(TutorialMovementSystem);
}

void FTutorialModule::ShutdownModule()
{
    UNREGISTER_SYSTEM_FUNCTION(TutorialMovementSystem);
}

#undef LOCTEXT_NAMESPACE
#undef SYSTEMS_NAMESPACE

IMPLEMENT_GAME_MODULE(FTutorialModule, Tutorial);

Blueprint

Create new game object that inherits from Object:

And name it BP_TutorialMovementQuery.
Add BP_TutorialMovement component and actor proeprties to tell over what systems world elements this query wants to iterate over.

Here Actor is Actor and Movement is BP_TutorialMovement component.
Create new game object that inherits from UScriptableSystem:

And name it BP_TutorialMovementSystem.
Override On Run event:
Create Query node and assign BP_TutorialMovementQuery class to it:
Create Lazy Iterate node:
Perform update on yielded object:

Note that Movement::Value is multiplied by Delta Time provided by On Run event.

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Setup game

Create new data asset that inherits from USystemsPipeline:

And name it DA_TutorialPipeline.
Add components:
- C++
- Blueprint
Add persistent systems:
- C++
- Blueprint
Create new game object that inherits from ASystemsGameMode:

And name it BP_TutorialGameMode.
Assign BP_TutorialPipeline to Systems Pipeline property:
Assign BP_TutorialGameMode to level you want this pipeline to run on:
Put some of BP_Entity actors on level, run game in PIE and see systems performing!

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

C++ API Reference

Structs

Classes

Functions

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Structs

Documentation built with Unreal-Doc v1.0.8 tool by PsichiX

Struct: `FActorsIter`

struct SYSTEMS_API FActorsIter;

Reflection-enabled

Specifiers:

BlueprintType

Query iterator over systems world actors.

See USystemsWorld::Actors.

Methods

`Adapt`

public:
template <typename ADAPTER>
TIterAdapt<Self, ADAPTER> Adapt(
    ADAPTER Adapter
);

Injects custom iterator adapter into the chain of iteration.

Useful only for really custom/advanced solutions that cannot be solved with regular iterators.

Note

ADAPTER should implement iterator adapter methods. Yielded values share same type wit iterator that wraps this adapter.

Systems - Modular and scalable game architecture for orthogonal game logic