My design style
Last updated
Last updated
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.
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 .
The debugging standards are slowly being enforced throughout my plugins. So these standards might not be found in my plugins *yet*
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.
Try to provide a ImGui debugger through Cog. ()