Unreal Engine 5 Modular Gameplay. Lyra, Game Features and plugins.
Unreal Engine 5 ships a modular stack, Game Features, Modular Gameplay and the patterns Lyra demonstrates, that most teams adopt halfway and then fight. We draw the boundaries properly: features that load, activate and tear down cleanly in a packaged build. Work starts with an Architecture Diagnostic from $749, and the first call is free.
The modular problems we're hired for.
Where the modular stack stops being free and starts needing an architect.
Experiences that load in the editor and vanish in the build
Primary asset rules, plugin content mounts and chunk assignment. The gameplay code is usually fine; the Asset Manager configuration is not.
Game Feature actions firing in the wrong order
Actions that assume a pawn is ready before its components exist. We put the work on the init state chain instead of on a timer and a hope.
Component injection without touching base classes
Adding behaviour to pawns, controllers and game states through the component manager, so a feature never forces an edit to a shared class.
Ability sets granted per experience
GAS abilities, effects and attribute sets bundled behind a feature, granted on activation and removed on deactivation. See the ability pipeline case.
A plugin dependency graph that will not link
Module load phases, public and private dependencies, and the circular references that appear once two features both want the same shared type.
Retrofitting modularity onto a monolith
Finding the seams in a codebase that already ships, then moving one feature at a time behind a boundary. See the modular inventory case file.
Editor and runtime split
Tooling that must not ship, gameplay that must, and the module boundary that keeps editor-only code out of the packaged target.
Borrowing from Lyra without forking it
Taking the experience, pawn data and ability set patterns into your own project, rather than inheriting a sample you then have to maintain.
Structure on file.
Under NDA. Names sealed, outcomes documented.
Modular, or just more folders?
Modularity is a cost paid up front against a saving later. One linear campaign, one team, one shipping date: a clean monolith is the cheaper answer, and we will say so. Several modes, several teams, or content that has to ship on a cadence the main branch cannot hold: that is when plugin boundaries start paying for themselves, and when drawing them badly starts costing real money.
The diagnostic answers which one you are before any restructuring begins. If the blocker turns out to be combat rather than structure, start with UE5 Gameplay Ability System development instead, or read what drives UE5 systems architecture cost.
Need help with a difficult UE5 problem?
Architecture Diagnostic
From $749A focused technical review of your project's architecture, performance or multiplayer systems.
Larger development engagements are scoped individually. Co-dev vs outstaffing vs contractor
Before you restructure.
Anything else? Ask us directly, or read the UE5 engineering field notes.
Do we have to use Lyra to get modular gameplay?
No. Modular Gameplay and Game Features are engine plugins that work in any Unreal Engine 5 project. Lyra is a reference implementation built on top of them. Most teams are better served borrowing Lyra's patterns, such as experience definitions and ability sets, than forking the sample itself.
What is a Game Feature Plugin, and when is it worth it?
A Game Feature Plugin is a self-contained plugin holding the code, content and actions for one slice of gameplay, which the engine can register, load and activate at runtime. It earns its cost when several modes or teams need to ship independently. For a single linear campaign it usually adds ceremony without payback.
Can you retrofit Game Features onto a project already in production?
Yes, and it is the more common engagement. The work is extraction rather than rewriting: find the seams in the existing monolith, move one feature behind a plugin boundary, prove it activates and deactivates cleanly in a packaged build, then repeat. Each step ships on its own.
Why do our game feature plugins work in the editor but not in packaged builds?
Almost always Asset Manager configuration. Plugin content is only cooked when a primary asset type points at it, so an experience or feature data asset that resolves in the editor can be missing from the package. The fix is in the primary asset rules, the plugin's content mount and the chunk assignment, not in the gameplay code.
How do modular features interact with the Gameplay Ability System?
Cleanly, if the grant path is data-driven. Abilities, effects and attribute sets are bundled into ability sets that a feature grants on activation and removes on deactivation, so a mode can add combat without the pawn class knowing the mode exists. Ad hoc grant calls scattered through actors are what makes deactivation leak.
Do plugins slow down cook and iteration times?
Well-drawn plugin boundaries usually improve iteration, because a change inside one module relinks that module rather than the whole game target. Cook time suffers when plugins depend on each other in a cycle, or when everything is marked as always-cooked. Both are measurable and fixable.
Who owns the plugin boundaries after handoff?
Your team. Engagements end with the dependency graph documented, the module load phases explained and a written rule for what may depend on what, so the structure survives the next feature without us.
Put the structure on screen.
Bring the feature that will not activate, or the monolith nobody wants to split.