My design style

How are my plugins/systems designed?

Over-arching goals

• Create a suit of tools, systems, plugins, workflows and more, that tries to be as design agnostic as possible. Slowly creating a large collection of code that can be re-used between projects, no matter their genre or requirements. This can be thought of as "creating an ecosystem/SDK"

• Minimize duplicate work as much as possible.

• Create a "golden path" of development. The clearer this path becomes, the faster development of each project becomes.

System design

Systems can be defined as a plugin, module, a small set of classes, or as an extension in another system like an equipment system in an inventory system. But most of the time, it's just considered as a plugin.

• I will NOT be supporting replication/multiplayer in any of my plugins other than Inventory Framework. I am finished with multiplayer projects.

• Rarely create parent actors or override important classes, such as the game instance. Utilize subsystems, actor components and such as much as possible.

• Plugins should try to be self-contained. If they require another plugin to work, that other plugin should be design-agnostic.

  • Do not recreate a system from another plugin just to get around this. It's better to break this rule rather than create duplicate systems. For example, a broadcast system like GameplayMessageRouter should never have duplicates in other plugins.

    • Unfortunately, this rule might be broken in plugins that are planned to be released to the marketplace because of the marketplace dependency rules.

• Try to enable as much Blueprint support as possible.

  • Exceptions are made when Blueprint support might cripple or highly complicate a systems workflow.

• Enable cross-plugin integration through preprocessor macros.

  • For example; TagFacts will broadcast a message through Hermes if the plugin is installed.

Debugging standards

The debugging standards are slowly being enforced throughout my plugins. So these standards might not be found in my plugins *yet*

• Try to provide a ImGui debugger through Cog. (Documentation)

  • This is mostly just done for systems that are difficult to debug through the Blueprint Debugger tool or if the engine has no other suitable alternative debugger.

• For functions with fail states where a simpe boolean doesn't cover all fail states, try to include a FString parameter that explains why it failed.

• Add log messages in a custom category or print to the screen if necessary.

  • Most custom categories are just called Log with the name of the module appended to the end. In some rare circumstances, a custom log might be made for a specific system inside of a module.