System Overview

System Structure

The system consists of several Actor Components, each of them is responsible for handling different functionality. Since they are components they can be attached to other actors. In the system they can be divided by: the ones added to the Player and the ones added to the Interactable Objects. Their default parameters can be easily customised by selecting them, either inside of a Blueprint class or Actor in the level.

Changing Component parameters inside the Player Controller

Changing Component parameters on the Level Actor

Gamemode important classes

The project’s gameplay logic is organized across several Unreal Engine classes, each responsible for a specific layer of functionality. This separation keeps the project modular, readable, and easier to maintain.

The Player Controller is intentionally used as the “logic brain” of the player, reducing complexity inside the Character class.

Gameplay logic is kept lightweight inside Player Character to maintain a clean separation from the Controller. It also gives an option to move all the nodes to your Character Class without re-parenting.

The HUD acts primarily as a display layer - gameplay decisions remain in the Controller. It creates WBP_RPG_HUD on BeginPlay and adds it to the viewport. Also calls the Show/Hide Loot Bar events - through BPI_HUDManager.

The Game Instance provides persistent global data across level transitions and manages the save system.

Class	Main Role	Key Responsibilities
BP_RPGInventoryPlayerController	Central gameplay logic	Input, component management, game flow
BP_RPGInventoryCharacter	Physical embodiment	Animation, sockets, mesh operations
BP_RPGInventoryHUD	Visual user interface	Displays game state, updates widgets
BP_RPGInventory_GameInstance	Persistent data	Saving/loading, global information

UI Communication

The project uses an interface-based communication system to handle interactions between individual Item Slot Widgets and their parent UI containers (such as Player Inventory, Storage, or Vendor screens). This approach ensures clean separation of responsibilities and allows all inventory-related UIs to share consistent behavior.

The interface acts as a common communication layer, allowing Item Slot Widgets to notify the parent UI about user interactions without needing to know the parent’s specific type. This keeps the system modular, reusable, and easy to extend.

1. Item Slot detects user input events such as: On Clicked, On Pressed/Released, OnDragStarted/Ended, etc.

2. Instead of directly executing logic, each Item Slot calls the appropriate interface function, passing information about: Slot Widget Reference, Slot Index.

3. The parent UI (e.g., PlayerInventory, Storage, Vendor) implements the interface and interprets these events according to its own rules - for example: splitting stacks, transferring to other slots, etc.

The benefits of using this approach are:

• Decoupled Design: Item Slot Widgets remain generic and reusable across different UI contexts.

• Consistency: All inventory-like widgets respond to interactions in the same standardized way.

• Scalability: New UI types (crafting stations, equipment screens, etc.) can be added simply by implementing the interface.

• Clean Code: Reduces clutter inside widgets and prevents cross-widget dependencies.