General plugin design approach

Hi,
I’m developing an inventory system as a plugin so I’ll be able to reuse it in later projects.
As an inventory system, I need to include UI and input processing in the plugin but here I approach some design questions that I’m not sure how i should solve.
Generally, I like to encapsulate all UI interactions and management in the HUD class, and the Input in the controller class, but doing so, hurts the plug&play idea in the plugin development.
It forces the client (me in other projects) of the plugin to rewrite all the UI and Input code in the specific HUD and controller classes of each project because I can’t really create these classes specifically for the inventory system, it would be weird, isn’t it?
Is there some other known approach for solving this that you familiar with?

2 Likes

Hi,
The whole idea of the new Enhanced Input plugin introduced in 5.0 is that inputs are stored as assets and can be enabled and disabled easily based on context. If you read through the documentation you should find what you need: Enhanced Input in Unreal Engine

The gist of it would be that when your UI becomes relevant you can enable the right mapping context and encapsulate your input either directly inside the UI, or inside a component. You could make a set of functions/macros inside blueprint libraries to accelare the setup.

If you want something more advanced (understand more powerful but more complex to setup) you should have a look at the Modular Game Feature plugin.

Presentation from 2 years ago: https://www.unrealengine.com/en-US/blog/modular-game-features-in-ue5-plug-n-play-the-unreal-way

Documentation: Game Features and Modular Gameplay in Unreal Engine

But keep in mind that it’s not widely known by the community yet, and might not yet be production ready.

Hi, thank you for the reply and the presentation resource, I’ll look into it.
I’m aware of the enhanced input system and I use it in my plugin, but if I understand it correctly, that doesn’t solve the point I raised. Because still, you need to process the input event somewhere, and that’s where the problem arise.
What you described is exactly what I’m currently doing, but that’s not what I want, because as a project progresses, you will have more and more different blueprints that handles input events, which will start to be convoluted to search through. That’s why I would’ve liked it all to be handled in one BP like the controller for example, but I’m not sure that it is possible if I want my game to be built with say 10s of plug&play plugins.