What is Dynaros?

Dynaros is a suite of Game Design Extensibility Plugins for Unreal Engine from Ganivyr.

Each Dynaros product focuses on one gameplay responsibility: interaction, inventory, building, quests, dialogue, world state, persistence, and other systems as the suite grows.

The goal is not to make your project belong to Dynaros. The goal is to give you reusable systems that can fit into your project.

Built to fit. Yours to shape.

The Short Version

Dynaros products are designed to be:

• Thoughtful: architecture, defaults, docs, and APIs should have reasons behind them.
• Adaptable: you can start simple and go deeper when your project needs more control.
• Open: your project architecture, source-level understanding, and integration choices matter.

You can use a single Dynaros product on its own, or combine several products when that helps your game.

Modular By Default

Dynaros is not intended to be one giant plugin that owns every gameplay feature in your project.

A project should be able to install only the systems it needs. Interaction should not require Inventory. Inventory should not require Quest. Nexus should help coordinate products without becoming the hidden owner of their behavior.

When several Dynaros products are installed together, they should feel consistent and easier to connect. But the ecosystem advantage should not become forced dependency.

Standalone Systems

Every Dynaros system is meant to provide value within its own responsibility.

For example, Interaction answers:

How does one gameplay object request an interaction from another?

It does not decide what a door, resource node, NPC, crafting station, or quest objective does after that request arrives. Those outcomes belong to the actor, project, or gameplay system that owns them.

That boundary keeps each product reusable.

Progressive Depth

Dynaros is meant to meet you where you are.

If you want guided setup, use the simple path. If you want direct Blueprint work, use the components, settings, events, and data assets. If you want deeper control, use the C++ APIs, source, extension points, and architecture notes.

You are not locked into one level. A developer may use guided setup for one feature and deep C++ customization for another.

Dynaros Nexus

Dynaros Nexus is the guided coordination product for the Dynaros ecosystem.

Nexus can help you discover installed systems, adjust shared settings, inspect status, manage debug options, and reach relevant documentation from one place.

Nexus makes Dynaros easier to manage. It does not make Dynaros possible to use.

Individual products remain usable directly. Nexus coordinates; products own their own gameplay behavior.

Using Dynaros With Your Own Systems

Dynaros is expected to coexist with project-specific code and third-party plugins.

A Dynaros product should expose reasonable integration points such as components, interfaces, events, public APIs, data-driven mappings, adapters, or configuration hooks where they fit the problem.

First-party Dynaros integrations may be smoother, but third-party and custom integrations should still be treated as normal use cases.

Source Access

Source access is part of the intended product experience.

You should be able to inspect how a system works, understand the architecture, modify it for your project where the license allows, and build against those changes.

Readable source, clear naming, responsibility boundaries, and maintainable structure are part of the product, not extras.

API Stability

Stable APIs should be safe to depend on.

Dynaros should prefer additive changes, clear deprecations, and migration notes when behavior changes. Experimental APIs may change more freely, but they should be marked that way.

When breaking changes are necessary, release notes should explain what changed, why it changed, who is affected, and how to migrate.

Documentation As Product

The docs are part of what makes Dynaros usable.

Public functionality should be documented with the level of depth it deserves: purpose, usage, concepts, configuration, examples, extension points, API surfaces, integrations, limitations, diagnostics, compatibility, and migration guidance where relevant.

If something public is hard to understand from the docs, that is a product issue worth improving.

Release Philosophy

Dynaros releases when Ganivyr is ready to stand behind the product or feature.

Stable means supported and intentional. Experimental means usable but still subject to change. Deprecated means available for compatibility but not recommended for new work.

The aim is steady evolution without making developers pay for that evolution through casual breakage.