Products
Dynaros plugins are independent products, rather than one monolithic plugin containing every system a game might need.
Each product focuses on one gameplay responsibility. You can use one Dynaros system by itself, combine several systems in the same project, or connect Dynaros to your own project-specific code.
The status labels below describe how mature each product is today. They do not describe how important a system is or whether it belongs in the long-term suite.
Suite Direction
Section titled “Suite Direction”Dynaros is designed as a library of gameplay building blocks.
One project might only need Interaction. Another project might combine interaction, inventory, quests, dialogue, gathering, crafting, building, skills, progression, persistence, world state, and other systems into a larger gameplay foundation.
The important part is that those systems should stay reusable without becoming inseparable. Adding one Dynaros product should not quietly force your project to adopt the whole suite.
Plugin Suite
Section titled “Plugin Suite”Reusable interaction behavior for players and world objects through components, interfaces, and a project-independent interaction flow.
Building placement and construction-related gameplay rules with system-level ownership.
Resource nodes, harvesting rules, rewards, depletion, respawn behavior, and gathering flow.
Item storage, containers, stacking, transfers, and transaction APIs.
Equipment slots, loadouts, and equip/unequip rules that can integrate with inventory.
Recipes, validation, ingredient requirements, creation results, and crafting integrations.
Skill progression while allowing each game to define its own skills, rewards, and content.
Unlocks, requirements, advancement, and persistent player progression beyond a single skill.
Reusable numeric gameplay stats such as health, stamina, mana, hunger, and temperature.
A potential lightweight ability plugin scoped to stay distinct from Unreal’s Gameplay Ability System.
Quest definitions, runtime quest state, objective coordination, completion, failure, and persistence.
Generic goal tracking for quests, tutorials, achievements, challenges, and other systems.
Conversation flow, choices, conditions, speaker data, and branching dialogue.
Data-driven loot tables, weighted rolls, contextual modifiers, and structured reward resolution.
Serialization, restoration, versioning, and migration across installed Dynaros plugins and project systems.
Spawn eligibility, population rules, lifecycle coordination, and PCG-compatible spawn policies.
Game time, calendar rules, scheduling, day/night progression, and time-based queries.
World-level rules and persistent state that should not belong to individual actors.
Faction relationships, reputation values, standing tiers, and reputation-based requirement queries.
Persistent achievements and challenge-style goals that observe gameplay events.
How the Systems Fit Together
Section titled “How the Systems Fit Together”Dynaros systems communicate through clear ownership boundaries.
Game / Player Input vReusable Component or Interface vOwning Gameplay System vRules, validation, and state changes vWorld / UI / progression responseEach product owns the logic that belongs to its domain and exposes the information other systems need to respond.
For example, Interaction can identify that a player requested an interaction with a harvestable object. Gathering can decide what harvesting means. Skill can respond by awarding progress. The interaction code does not need to understand resource yields, inventory storage, or skill calculations.
That separation is what lets Dynaros systems work together without turning into one large, tangled product.
What To Expect From A Dynaros Product
Section titled “What To Expect From A Dynaros Product”Each product area should help you understand four things:
- what the product does
- what it does not own
- how to get a first working result
- where to go for deeper configuration, integration, or reference details
As products mature, their docs may include guides, recipes, Learn pages, integrations, troubleshooting, advanced architecture notes, release notes, and API reference.
Not every planned product has all of that documentation yet. The current docs will grow alongside the systems.
Nexus And Product Docs
Section titled “Nexus And Product Docs”Dynaros Nexus is a guided coordination product for the wider suite. It can make installed systems easier to discover, configure, inspect, and work with from one place.
Nexus does not replace the individual product docs. If you want a guided route, Nexus-related pages should help. If you want to work directly with a system’s components, APIs, settings, data assets, or extension points, use that product’s own docs.
The short version:
- Nexus helps coordinate.
- Each product owns its gameplay behavior.
- Your project decides how much of the suite to use.
Working With Existing Projects
Section titled “Working With Existing Projects”Dynaros is meant to fit into projects that already have their own actors, systems, plugins, and conventions.
Where possible, products should provide component-first workflows: add a Dynaros component, configure it, connect the relevant events, and get a useful baseline working.
For deeper customization, products may expose interfaces, delegates, subsystem APIs, data assets, C++ classes, or replacement points. You should not have to abandon your project architecture just to use one Dynaros system.
Using One Product Or Many
Section titled “Using One Product Or Many”Every Dynaros product should provide value on its own.
When multiple Dynaros products are installed, they may offer smoother integrations with each other. Those integrations should be deliberate and optional unless there is a real architectural reason for a dependency.
That means you can start small. If Interaction solves your current problem, use Interaction. If your project later needs Inventory, Quest, Dialogue, or another system, those products can join the project without changing the basic promise.
Configuration
Section titled “Configuration”Many Dynaros systems are expected to support scoped configuration:
Project defaults -> product defaults -> per-instance overridesThat means a project can set common behavior once, while still allowing individual actors, components, or use cases to override details when they need to.
How To Choose A Product
Section titled “How To Choose A Product”Start with the gameplay responsibility you are trying to solve.
If you need actors to notice and request interactions, start with Interaction. If you need resource harvesting, look at Gathering. If you need storage and item movement, look at Inventory. If you need conversations, look at Dialogue.
If your task crosses several responsibilities, start with the product that owns the first action in the workflow, then follow integration links from there.