UE5 Plugin Development

Hello! I'm PanKUN.

This time, it's about turning features into plugins, which will be useful for future projects if you keep it in mind when developing UE5 games.

Overview

When creating a certain function of a game, paying attention to the granularity of responsibility has the following merits.

• Maintainability Since functions are grouped together, it is easy to understand the scope of influence of bug fixes and specification changes.
• Readability "Look at this plugin for this function" becomes clear, improving the overall visibility of the project.
• Reusability When taking it to another project, copy-pasting the plugin or adding dependencies is all that's needed.
• Compatibility with team development It is easy to divide roles and draw module boundaries for each person in charge.

In this article, I will summarize focusing on "what to be conscious of when cutting out as a plugin to make it beneficial".

Timing to be conscious of plugin creation

Personally, if it fits any of the following, I try to stop and consider it as a "candidate for a plugin".

• Functions that are likely to be reused in other projects in the future
• When "game-specific logic" and "common mechanisms" start to mix
• When it is a "function independent of game execution" such as Editor extensions and tools

Also, this is not a recommendation to turn everything into plugins, but rather "functions you want to survive across projects" are easier to benefit from later if separated as plugins from the beginning.

How to decide the granularity of responsibility

The guidelines I often use when deciding the granularity of responsibility are like this.

1. Can it be explained in one phrase?

Whether the description of the plugin can be expressed in one phrase.

• OK examples:
  • This plugin handles save/load management in the game
  • This plugin summarizes camera tracking, shaking, and zoom control
• NG examples:
  • It saves, displays UI, and also tweaks enemy parameters

2. How to separate game-dependent parts

If the code on the plugin side has direct references to:

• Project-specific GameMode names
• Specific character classes
• Specific map names

Then reusability drops dramatically.

So,

• Plugin side: Define abstract interfaces and events
• Game side: Implement them and write "concrete processing"

Procedure for creating a plugin

The position of fine buttons changes slightly depending on the UE version, but the flow is like this.

1. In UE5 Editor Plugins -> Select template from "New Plugin"
   • Select according to usage such as Runtime Plugin / Editor Plugin
2. C++ / BP is generated in Plugins/YourPluginName/ of the project
3. In .uplugin of the plugin, describe
   • Module type (Runtime / Editor)
   • Dependency modules
4. In the case of C++, write initialization and release processing in StartupModule / ShutdownModule of YourPluginNameModule class
5. After that, build functions "with the same feeling as normal project code" However, be careful not to depend heavily on game-specific names

There is no need to aim for perfect design from the beginning, first

1. Create a box with a granularity of "This chunk seems like it can be independent as a plugin"
2. Gradually turn parts you care about into interfaces while using it

Then a "nice boundary of responsibility" will naturally become visible.

Examples of failures that tend to happen when creating plugins

Here are some patterns I got stuck in / saw.

1. Stuffing everything into one plugin

If you can no longer explain it in one phrase, it is easier to think that it is time to split the plugin.

• In a plugin named "Common System"

  • Save/Load
  • Common UI parts
  • Debug console
  • Network wrapper

  As a result of putting all of them in, it becomes just a huge project.

2. Directly writing game-specific classes

• Directly referencing AMyGameCharacter or AMyGameGameMode in the plugin code
• The moment you take it to the next project, all compilation errors

Portability increases dramatically if you use interfaces (UInterface and Delegates) like this:

• Have "information the plugin wants" supplied from outside via events or functions
• The plugin itself operates on the premise that "someone will implement this"

Summary

• When making a game with UE5, it is easier later if you separate "functions you want to use in the next project" as plugins from the beginning
• It is easy to organize if you think about the granularity of responsibility based on
  • Can it be explained in one phrase?
  • Is it separated from game-specific parts?
• There is no need to make it perfect suddenly
  • First, "Let's make this function a plugin"
  • It is realistic to adjust boundaries and interfaces while using it