Architecture Overview

General Architecture

RPG Engine v6 is built around a fully modular character architecture. Unlike the previous monolithic approach, the current version uses one universal character class, BP_RPG_Character, together with a mediator-driven component system.

The goal of this architecture is to reduce coupling, make systems easier to disable or replace, and allow one project foundation to support very different actor types without duplicating logic across many separate character blueprints.

At the center of this structure is BP_ModulesMediator. This component is responsible for coordinating module initialization, managing character states, and acting as the only communication bridge between gameplay modules.

Universal Character Class

RPG Engine v6 uses a single universal player character class:

• BP_RPG_Character

This class is designed to work with a modular set of actor components instead of embedding most gameplay logic directly inside the character blueprint itself.

Character Modules

The following gameplay modules are used in the current architecture and can be attached to BP_RPG_Character depending on the selected configuration:

• BP_AbilityComponent
• BP_BuildingComponent
• BP_CharacterSkinComponent
• BP_DialoguesComponent
• BP_BuffComponent
• BP_EffectsComponent
• BP_StatsComponent
• BP_ModulesMediator
• BP_MovementComponent
• BP_TradingComponent
• BP_VehicleComponent
• BP_QuestComponent
• BP_EquipmentComponent
• BP_FirearmsComponent
• BP_GrenadesComponent
• BP_InputsComponent
• BP_InteractComponent
• BP_MeleeComponent
• BP_PlayerComponent
• BP_RespawnComponent

This list represents the main modular gameplay layer used by the player character architecture in v6. Different actor types may use different subsets of these systems depending on the selected module configuration.

ModulesHUB Configuration

The mediator receives its module configuration through an instance-editable variable named ModulesHUB, located inside BP_ModulesMediator.

ModulesHUB is a data asset that inherits from BP_ModulesHUB. Inside this asset there is a variable called Modules. Each entry in this array is a structure with two fields:

• ActorClass
• Enabled

If Enabled is set to true, the corresponding component is considered part of the current actor configuration. If it is set to false, that module is ignored.

Because ModulesHUB is instance-editable, each class that uses the mediator can configure its own active module set directly through the Details panel.

ModulesHUB Presets

RPG Engine v6 already includes multiple base presets for different actor types. Current examples include:

• DA_MHUB_Dummy
• DA_MHUB_GuardMelee
• DA_MHUB_GuardRanged
• DA_MHUB_MeleeAI
• DA_MHUB_Player
• DA_MHUB_QuestNPC
• DA_MHUB_RangeAI
• DA_MHUB_ShopNPC
• DA_ModulesHUB_BaseAI

These presets allow different actor classes to use the same core architecture while enabling only the systems they actually need.

Initialization Flow

Module initialization is coordinated by BP_ModulesMediator during BeginPlay.

At startup, the mediator reads the configuration from ModulesHUB, gathers all actor components that belong to the current character, and stores them in a dedicated internal array. After a delay of 0.2 seconds, the mediator calls BPI_SM_Initialization on every collected component.

BPI_SM_Initialization is part of the shared BPI_StateMachine interface and represents the first layer of initialization. Its purpose is to initialize all important internal variables inside each component.

After this first initialization step is complete, each component triggers its own ComponentInitialized event. The character class then calls a function named TryLaunchGame.

TryLaunchGame checks how many components were initialized successfully. If all required components are ready, the character calls StartupEventServer in the mediator. This marks the beginning of the main startup layer, where the project continues with the actual gameplay initialization flow such as save loading, menu-driven startup overrides, and other runtime startup logic.

State-Centered Coordination

BP_ModulesMediator is not only an initialization coordinator. It is also the central state manager of the character.

The mediator manages the character’s active states and controls how gameplay modules request state changes. Instead of allowing modules to talk directly to one another, RPG Engine v6 routes state-related communication through the mediator.

This makes the mediator the single source of truth for state transitions and helps keep the architecture decoupled.

Interfaces and Communication Rules

All gameplay modules implement the shared BPI_StateMachine interface. This interface includes the BPI_SM_Initialization function and serves as the common low-level communication contract for the modular state architecture.

In addition to that, the mediator implements the BPI_ModulesMediator interface. Other components use this interface to request or query state changes without creating hard references between modules.

Important mediator interface functions include:

• BPI_MM_ActivateState
• BPI_MM_DeactivateState
• BPI_MM_DoesStateExist
• BPI_MM_DoesAnyStateExist

This means that modules do not communicate directly with each other. Instead, they communicate only with the mediator.

For example: — A gameplay module that wants to activate a state sends the request through BPI_MM_ActivateState. — A module that wants to remove a state uses BPI_MM_DeactivateState. — A module that needs to check whether a specific state is currently active uses BPI_MM_DoesStateExist. — A module that needs to know whether any state from a list is active uses BPI_MM_DoesAnyStateExist.

This rule is one of the main architectural principles of v6 and is critical for reducing dependency chains between systems.

Module-Specific Interfaces

Besides the shared state interfaces, each gameplay module may also implement its own dedicated interface. These interfaces are intended to be used only by the mediator and the corresponding module.

This approach helps isolate module logic and ensures that individual systems do not create unnecessary direct connections to unrelated components. As a result, the project remains easier to scale, maintain, and refactor over time.

Architectural Purpose

The architecture of RPG Engine v6 is designed to solve several problems at once:

• Reduce monolithic blueprint logic.
• Lower coupling between gameplay systems.
• Make it easier to enable or disable features for different actor types.
• Keep one universal character architecture for player and AI variants.
• Centralize state control and module orchestration in one place.

This modular mediator-based design is the main architectural difference between RPG Engine v5 and v6 and is the foundation on which all other gameplay systems are built.