# 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](/varian-docs/tag-facts/integrations.md#hermes).

## Debugging standards

{% hint style="warning" %}
The debugging standards are slowly being enforced throughout my plugins. So these standards might not be found in my plugins \*yet\*
{% endhint %}

* Try to provide a `ImGui` debugger through `Cog`. ([**Documentation**](https://varian.gitbook.io/varian-docs/imgui-cog-setup/))
  * 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://varian.gitbook.io/varian-docs/my-design-style.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.