General Information
All non self-explanatory blueprint classes and most functions or blueprint graphs in general, have a golden comment within them that explain what the class is for and possibly how it works. Also all events are inside comments to make the overview a bit easier as well as a convenience in finding a specific event when looking at a blueprint graph due to the comment title (and bubble) being larger than the event title. The blue comments hold interface events.
Also, all blueprints, variables and functions contain descriptions either through comments or through the descritption field in the details panel.
You’ve probably noticed that almost all files are inside the OGMUIS folder instead of directly in the Content folder. This template was made to be used as the “main” project due to having multiple project settings set up BUT that parent folder makes migrating parts of the template into your own project (or the other way around) much cleaner. In most cases, folders like “Characters” or “GameModes” already exist, and mixing them with template content can get messy fast. If you do want everything in one place, feel free to move the files after migrating. If not, no need to thank. Just smile, nod, and enjoy the folder structure.
Common UI
Overview
You will notice throughout the template that the widgets do not inherit from “User Widget” but instead from “Common User Widget” and “Common Activatable Widget”. That’s due to a default plugin called “Common UI” which was used for the UI. It’s also the primary system behind my other template OG Main Menu System.
Citing the Unreal Engine Common UI Documentation:
“Common UI supports the development of cross-platform UIs with complex navigation, such as menus with layers, submenus, or popups. Originally developed for UI in Fortnite, this plugin is available to Unreal Engine users through the Plugins menu.”
How we use it
Common UI offers plenty of functionality but in this Kit it will be used for 2 reasons.
First, this makes it very easy to have multiple layers and focusing on the top most “leaf”. This is elaborated further in the Common Activatabale Widget section.
Second, Common Text/Border Syles and Common Base Buttons.
Activatable Widgets
Within Common UI, only certain widgets are converted into nodes for the purpose of handling input, and only widgets that are ready to handle input receive input. These widgets are called activatable widgets, and they are considered “active” if they are ready to receive input.
Activatable widgets help manage input flow, especially in overlays. If an overlay widget is dismissed, CommonUI ensures that input is routed to the next active widget, even if it’s on a lower UI layer. Only the topmost active leaf receives input at any time, so lower layers don’t need to worry about being inactive if they’re still in use.
Throughout the template, you will notice widgets inheriting from the Common Activatable Widget class. Widgets inheriting from this class usually aren’t created like normal User widgets usually would. Instead they get pushed on Stack layers and become active by doing so. For your convenience, all activatable widgets in this kit have an “AWBP_” prefix.
Layers in Common UI
In this template, different types of UI content are managed by specific layers. Each layer represents a stack of widgets that can be pushed or popped/deactivated to control which UI elements are visible at a given time.
The layer structure used in this template consists of:
- Game: For HUD, Main Menu and similar elements which kind of take the “main UI” role.
- GameUI: For gameplay-related widgets (e.g., Skill Selection).
- Menu: For settings or other windowed screens.
- Modal: For overlays like Pop-Up windows.
When a widget is pushed onto a layer with existing content, it replaces the current widget until it is deactivated (popped off). For example, pushing a new UI element onto the GameUI layer replaces the old one.
Each layer operates as a separate stack, so when a new widget is pushed onto a higher layer (e.g., Menu), the layers below it remain visible. This allows for flexible, non-overlapping UI structures. This means that there can be 4 Activatabale Widgets active at the same time. One for each layer.
Common User Widgets
They do offer some extra functionality but here they are being used as if they were simple user widgets. This way, if you wanted to extend on the Common UI functionality, you could without having to reparent or recreate widgets.
Common Styles
CommonUI comes with its own set of widgets, found under the Common UI Plugin section in the UMG Palette. Unlike regular UMG widgets, these don’t have built-in styling options. Instead, they use Common Style Assets to control appearance.
You’ll find the style assets of the OG Mobile UI System in the CoreUI folder, under the subfolders Button, Borders, and Text. Changing a style asset updates every CommonUI widget that uses it. For example, if you update the font of a CommonTextStyle asset, all CommonText widgets using that style will update automatically, making it easy to keep your UI consistent.
You can create new style assets by creating a Blueprint of the Style type that you want as you can see in the following image.
For More information, checkout the Common UI Quickstart Documentation.
Architecture
Gameplay Tags
Gameplay tags are probably the main foundation of the architecture in this kit. For those who don’t know what gameplay tags are, take a look at this article in the documentation.
In short, gameplay tags can be added and removed in the project settings and can be accessed in the entire project. They’re basically like actor tags, just hierarchical, accessible from everywhere, and much more consistent since there can’t be any typos—they’re defined in one place only.
In this kit, they’re used for identifying game levels like Level.Ch01.Lv01, items like Item.Boots.Golden, and UI layers as part of Common UI like UI.Base.Modal. They’re very lightweight and make the life of a UE dev much easier.
Game Instance
The Game Instance is probably the most important Blueprint in the entire Kit. It handles loading saved data from Save Game files so other assets can access it, and saves data whenever something changes. It also manages all the logic for player level ups and the Rewards system. Since you can earn rewards both in-game and in menus, and need to keep them when changing levels or maps, the Game Instance is perfect for this, it’s the only class that doesn’t get destroyed when switching levels/maps.
The Game Instance itself doesn’t reference many assets. Instead, other assets get data from it through interfaces or casting, depending on what makes the most sense.
Optimization
Unlike computers, mobiles usually have much less hardware power nowadays. That’s why a big focus in development was optimization.
You’ll come across a number of comments in the system that talk about how certain parts are optimized, but here are a few things that were done. First, soft references were used wherever it made sense. Furthermore, tick is disabled on all actors and components where it’s not needed.
Rarities
You will come across these 5 rarities when playing the game or using the syste,:
Common, Uncommon, Rare, Epic and Legendary.
All of these have an own set of Common Border Styles set up for them that make them have consistant colors across the entire project.
In addition to just colors, they play an important role in item level up multiplicators and define the chance that an item of that rarity is pulled when opening a chest.
UI
WBP_CmnUI
The “WBP_CmnUI” widget is the core widget which holds the stack layers onto which all activatable widgets get pushed on. To understand better what stack layers are, checkout the section on Layers in Common UI!
Additionally, this class handles pushing and removing widgets. This is handled by utilizing gameplay tags, one for each stack layer, then giving it over as an input through that function call, test which tag was given over and push the widget on the appropriate stack layer.
Main Menu
The dependencies in the Main Menu are pretty straight forward. The primary Main Menu widget is called “AWBP_MainMenu” and essentially holds all its tabs like “AWBP_BattleMenu”, “AWBP_ShopMenu” etc. . These hold references to their sub-widgets and so on. There is almost never a circular dependency.
Menu Feature Managers
Features like the calendar, AFK Hunt, and Tasks use Actor Components attached to “HUD_MainMenu” to handle their logic. These components inherit from “AC_Menu_Manager”. When the game starts, they get data from the Game Instance, which loads it from Save Game files. Their only job is to fetch information from the Game Instance and show it on widgets. Following the standard pattern, widgets reference the Actor Components, not the other way around. You can spot these managers by their “AC_Mgr” prefix, which stands for Actor Component Manager.
Buttons
Pretty much all Buttons inherit either from “WBP_BaseButton”, “WBP_GenericButton” or “WBP_IconButton”. The last two inherit from “WBP_BaseButton” as well which handles things like darkening the button while pressed. These button widgets are designed to be very customizable and allow for various styles.
Windows
Almost all Windows inherit from “AWBP_BaseWindow”. It’s also designed to be as customizable as possible. No matter what you want to change… the background, size, Title, Title type, Outline etc. . You name it.
Game
Maps
When a player presses play in the main menu, the selected level and its chapter are stored in the Game Instance. Then the game opens the Chapter Map.
Chapters are persistent levels, and the actual level loads based on what the Game Instance passed along. Technically, since all chapters are the same size, you could add all levels to every chapter. However, this setup allows for maps of different sizes or maps with areas that can’t be walked on.
Equipment
The equipment was designed in a way that every item can add to the health and damage values. However, the current setup is that all items give health besides weapons which only give damage and accessories give both. Also, any item can be upgraded in level and has a rarity that’s Common, Uncommon, Rare, Epic or Legendary.
Leveling up an item multiplies the base item attributes with values specified in curves and not only do the factors vary by level but also by rarity. The price it takes to level up an item is also defined in a curve.
Health and Damage
The total health and damage attributes are the sum of the health and damage values of all equipped items. Other items in the inventory are not being taken into account.
Power is calculated as a simple multiplication between the total health and damage of the player.
The System can be extended to utilize the calculated values in combat. Exactly, like in the OG Roguelike Mobile Kit .
Tutorials
Version Changes
V1.0.0
Initial Launch version.